'final' variables

Lionello Lunesu lio at lunesu.remove.com
Tue Mar 20 14:44:30 PDT 2007


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?

const would still exist, right? So you'd just keep using "const int x = 
...". The _only_ purpose of "final int y" is for code clarity, you don't 
have to scan a whole function to see what happens to that variable, 
since nothing will happen to it.

L.


L.



More information about the Digitalmars-d mailing list