Const template

[Andrei Alexandrescu (See Website For Email)]

Dave wrote:
> Andrei Alexandrescu (See Website for Email) wrote:
>> D is slated to have full-fledged compile-time reflection, meaning that
>> you can find out all information about any given symbol, during
>> compilation. So it turns out that a possible path to implement const is
>> to make it a template. Given an arbitrary struct Foo, you could define a
>> template called Const such that Const!(Foo) materializes into a struct
>> that holds a Foo* inside, and exposes only the non-mutating parts of Foo.
>>
>> So, given:
>>
>> struct Foo
>> {
>>   int alpha, beta;
>>   void nonmutator() { assert(alpha * beta != 0); }
>>   void mutator() { alpha = beta; }
>> }
>>
>> the template Const!(Foo) generates the code:
>>
>> struct Const!(Foo)
>> {
>>   private Foo* pFoo;
>>   this(inout Foo foo) { pFoo = &foo; }
>>   int alpha() { return pFoo->alpha; }
>>   int beta() { return pFoo->beta; }
>>   void nonmutator() { pFoo->nonmutator(); }
>> }
>>
> 
> But you could still trivially and legally subvert this 'const'-ness:
> 
>     Const!(Foo) c(Foo(100,200));
>     Foo* fp = *cast(Foo**)&c;
>     fp.alpha = 10000;
>     writefln(c.alpha);

Casts can break any design, so it's not phasing anyone off that they can 
break const. Besides, the fact that Const holds a pointer to the object 
as its first element is not something client code is allowed to rely on. 
This is a non-issue.

> So according to what Walter has said in the past about 'semantically 
> meaningful const' then it wouldn't be enough to base optimizations on 
> (even if the compiler could glean useful information from this).

With well-placed casts and simple operations you can subvert the 
workings of the garbage collector. The D compiler is not required to 
make every code that compiles, work as someone expects.

>> 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.
>>
> 
> Both "user-space" and "compiler-space" const has been discussed at 
> length in the past, and Walter's response has always been (paraphrasing) 
> "D won't have const unless it is semantically meaningful (100% 
> enforceable) by the compiler", which will never happen with a language 
> like D.

This statement must be understood in spirit. The spirit is, D shouldn't 
add a feature that fails spectacularly at providing a true guarantee, as 
C++ did. The design I suggested does without the actual feature.

D 2.0 will have const. Walter wants it as much as the next guy. The 
challenge is indeed finding something that has a good 
complexity/performance ratio.

What I like about the template const idea is that it is entirely 
automatic - the user doesn't have to annotate functions manually as 
being const or not. The template will extract with precision the part of 
a type that can be used without mutating the object. (Such a deduction 
can also be part of a built-in feature.)

To start talking about const, D must first address the inout issue, 
which is nothing short of a source of radioactive decay that affects 
negatively random parts of the language, which otherwise has a sound 
design. Walter acknowledges that there is a problem, but I don't think 
he and I have the same understanding of its consequences (which I 
believe are enormous).

Once inout is taken care of, we need to take a deep breath and address 
the issue of lazy (which is related), and only after that const can 
enter the debate table.


Andrei