D Language Foundation March 2023 Monthly Meeting Summary

[Dukc]

On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote:
> Walter also said that whether void initialization should be 
> allowed in pure code is a different question. Void initializing 
> an int and returning it isn't pure, is it? So maybe we should 
> disallow void initializations in pure code. He thinks that's a 
> reasonable proposition.

I disagree: it makes sense as is. Consider:

```D
@safe pure int fun()
{ int result = void;
   return result;
}

@safe void gun()
{ int a = fun(), b = fun();

   [a, b].each!writeln;
}
```

What are values of `a` and `b`? They are unspecified. Since `fun` 
is pure, the compiler might cache the unspecified value of `a = 
fun()` to `b`, but so what? `b` is also unspecified, so it's 
expected it could happen to always be same as `a`.

`pure` can and should be able to return unspecified values, as 
long as they're unspecified the same way for the same argument 
set. About what would be unspecified in different way, and thus 
impure, this is an example:

```D
int global;
@safe int impureFun()
{ int local = void;
   if (local < global) return global;
   else return local;
}
```

This also returns an unspecified value (unless `global == 
int.max`) but it's unspecified in different way depending on 
global state (never less than `global` at time of call) so the 
compiler rightfully rejects it if you try to mark it `pure`.