'final' variables

[Andrei Alexandrescu (See Website For Email)]

Benji Smith wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>>> This is the part I'm not sure about. As with C++'s "const", I don't 
>>> think the compiler can conclude anything and therefor it can't 
>>> optimize anything. A "final" variable is not constant.
>>
>> final int x = 42;
>>
>> Change that :o).
>>
>> Andrei
> 
> How does this interact with CTFE for variables that are declared as 
> const. With previous versions of the compiler, I know that it would try 
> to constant-fold this code, resulting in an inlined constant from the 
> result of the CTFE:
> 
>    const int abc = kaboom();
> 
> That code shouts out to me (and to the compiler) that the kaboom() 
> method MUST be evaluated at compile-time. But this code is not nearly so 
> clear:
> 
>    final int xyz = shabam();
> 
> Just because xyz can't be re-bound after its initial assignment doesn't 
> necessarily mean that shabam() should be executed at compile-time. With 
> the new const/final/invariant semantics, how will the compiler know when 
> to perform constant-folding (or, I suppose, "final-folding") on functions?

Undecided at this time. At least "static final" will take care of that - 
you can't dynamically-initialize statics.

Andrei