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`.
