Const template

[Frits van Bommel]

Andrei Alexandrescu (See Website For Email) wrote:
> Frits van Bommel wrote:
>> Andrei Alexandrescu (See Website for Email) wrote:
>>> The reflection mechanism would have to provide the information whether
>>> or not a given member function changes the object.
>>>
>>> The only drawback that I can think right now is that the compiler can't
>>> exploit this kind of constness with ease to generate better code; it's a
>>> "user-space" implementation with semantics that are hard to figure out
>>> at the compiler level.
>>>
>>> A minor drawback is that Const!(Foo) must be implicitly constructible
>>> from a Foo, but another in-design language feature (opImplicitCast) will
>>> take care of that.
>>
>> Correct me if I'm wrong, but I think none of this stuff will work for 
>> methods that are only declared instead of defined as well; 'const', 
>> implemented like this, wouldn't work for "header modules"...
> 
> That is correct. Interface functions, nonfinal methods, and 
> declared-only functions must be annotated manually. The same holds for 
> things like "pure". Hopefully they are only a fraction of the entire 
> const use, such that the burden of the programmer is reduced.

If explicit annotation is possible then this could work for this case. 
Especially if "dmd -H' automatically added these annotations where 
appropriate.



You didn't respond to my paragraph on classes though:

Frits van Bommel wrote:
 > I also don't see a way this can work for classes (in general). There's
 > no way to limit a non-final method to non-mutating operations that I'm
 > aware of, so it could easily be circumvented by subclassing. Even though
 > that would only allow direct access to non-private fields, mutating base
 > class methods could still be called for the rest (if available). So then
 > the only way to get a const version of a class would be if the class
 > doesn't allow mutations anyway (like java's String). Which leaves us
 > right back where we started :(.
 >
 > And I don't think a 'const' implementation should work for structs and
 > not for classes...