Const template

[Dave]

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

I wish Walter would have agreed with many of us that it (casts breaking any design) is a "non-issue" 
for going ahead with a 'semantically meaningful const' a year ago. I hope you can convince him!

>> 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.
> 

I agree. Just like in http://digitalmars.com/d/garbage.html where it's acknowledged that certain 
pointer operations should not be used on GC'd memory, I think a section like that on 'const' would 
be good enough as long as the compiler enforced what could reasonably be expected. "If you 
(intentionally) break it, you buy it."

>>> 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.
> 

I completely agree with this sentiment. In earlier discussions, there were designs that went even 
further, for example not being able to take the address of or cast from a const parameter, etc.

But IMO that sentiment has been subjectively and unevenly applied to different but often requested 
language requests over the years. Unfortunately the earlier const suggestions were a case where the 
same sentiment was not applied. IIRC, the majority of the "group" - many of which had a large amount 
of experience writing libraries with D - strongly favored a 'const' or 'readonly' even though the 
compiler could not always guarantee they couldn't be modified.

> 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