Current dmd aggressively expand const/immutable variables in optimization, but it reports unuseful errors against void initialized variables.
This code should compile, but doesn't.
void main()
{
int mx = void;
const int cx = void;
immutable int ix = void;
mx = cx; // Error: void initializer has no value
mx = ix; // Error: void initializer has no value
}
Comment #1 by k.hara.pg — 2012-10-04T06:44:44Z
Say more accurately, my argue is "such code should be semantically allowed by D front end". So, even if backend code generation might warn the using of unset variable, it is not bad behavior.
From the discussion in github, I've agreed that this is an invalid issue.
By Don Clugston,
> I am sorry, I'm completely unconvinced by this. If you write: "immutable int ix = void", there is no way, without breaking the type system, that ix could ever be given a value. Such code is simply wrong.
>
> Now we could change the meaning of "= void" to mean, set in a constructor. In that case, "immutable int ix = void;" and "immutable int ix;" are the same. Then no constant folding would ever be performed on something with a void initializer. I think that's a reasonable language change.
>
> But even in this case, the test code should not compile (it's neither in module scope, where there could be a static this, nor in an aggregate where there could be a constructor).
>
> The situation in bug 3449 is an entirely different issue.
Then, const/immutable local variables which initialized with void is meaningless.
Such compiler's behavior might not be so bad.