D Language Foundation March 2023 Monthly Meeting Summary
Dukc
ajieskola at gmail.com
Wed Apr 12 09:20:31 UTC 2023
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`.
More information about the Digitalmars-d-announce
mailing list