Logical const

[Steven Schveighoffer]

On Wed, 01 Dec 2010 12:43:38 -0500, Jesse Phillips  
<jessekphillips+D at gmail.com> wrote:

> Jordi Wrote:
>
>> On the other side, in D, it is a hint to the compiler but it will only
>> use it if is verifiable. If that is the case, why do we need the "const"
>> keyword in the first place? The compiler can already verify that the
>> code is const and do the proper opimizations.
>
> It can, unless the source is not available. Though it could probably  
> output the information when creating .di files.

This isn't practical.  .di files are not object files, so they can be  
altered too easily.

Note also that the compiler cannot do any optimizations for *const*  
functions, it can only restrict access (useful for programmer).

>> Steve's solution would be on the side of "useful for the programmer,
>> enforced by the compiler, uselss for the compiler".
>
> But it isn't enforced by the compiler. It can enforce that you only  
> modify things you claimed could be modified. But it can't enforce that  
> it is logically const. It could prevent the modifiable parts from  
> influencing the result, but then the requested caching isn't possible.

The current const regime cannot enforce that you cannot modify the logical  
state of the object, because it does not know if any global variables are  
part of the state.

Logically const cannot be enforced, and it cannot be prevented by const  
alone.

A pure function enforces that you are not modifying external state.  If  
storage for non-state data is allowed inside the object (thereby enabling  
logically const data), then special rules would need to be followed for  
pure and immutable functions.

-Steve