'final' variables

[Don Clugston]

Andrei Alexandrescu (See Website For Email) wrote:
> 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.

But presumably that would allocate space for the variable in the data 
segment.

int CTFE_function1(int x)
{
	static final y = CTFE_function2(x);
}

And that's a really clumsy construction for something which occurs so 
frequently.