The Status of Const

[Steven Schveighoffer]

On Mon, 16 Aug 2010 18:12:35 -0400, Tomek Sowiński <just at ask.me> wrote:

> Dnia 16-08-2010 o 17:17:32 Steven Schveighoffer <schveiguy at yahoo.com>  
> napisał(a):
>
>> * Perhaps a good starting point is to look at std.container.SList and  
>> see how const(SList!T) can be manipulated.
>>  We can start simpler than that.  Give a struct:
>>  struct Array(V)
>> {
>>   uint length;
>>   V *v;
>> }
>>  How can we turn Array!V into Array!(const(V)) implicitly...
>>  This will duplicate array tail-const, and be essential to making  
>> tail-const ranges.
>>  It should be a good starting test for any library/compiler solution.
>
> Nice litmus test. I thought about it for a while and came up with:
>
> Array!int arr = ... ;
> Rebindable!(const Array!V) r = arr;

Wait, is the length mutable in that type?  If so, that's better than I  
thought Rebindable could do...

We can move onto the next test:

Given:

class C {}

class D : C {}

convert Array!D into Array!(const C)

OK, maybe this is a more advanced test :)

I'd be happy with just proper factoring of const to be honest.

> It actually compiles if you remove the template constraint off  
> Rebindable. But tail const/immutable is generally desired so you'd end  
> up with rebindable everywhere making variable manipulation cumbersome,  
> the code less auditable, giving easy counter-arguments in language wars  
> ("D must resort to casts, so much for the type system revolution,  
> haha"), etc.

Naming is subject to debate.  I think with some functions to surround it,  
and better naming, Rebindable can be quite usable.  With aliases, you have  
the power to shorten anything.

e.g.:

template tconst(T)
{
    alias Rebindable!(const T) tconst;
}

tconst!T is pretty much as easy as @tail const(T).  But the implicit  
conversion *has* to be there.

> Plus, there's the merriness with shared (tail-shared structures, anyone?  
> and of course you'd want a tail-const view on it at some point, etc).

tail shared is similar to tail const.  But implicit conversions are not  
there.  It's more like tail-immutable.

> Rebindable (this name doesn't scale) would basically have to reimplement  
> all of D's type conversions via operator overloading, template  
> constraints, static ifs, and blunt casts. Like as if implementing all  
> this in a compiler alone wasn't hard enough...

I agree, compiler support would be easiest on the user.  In fact, compiler  
support to make rebindable possible may be more difficult than compiler  
support for tail-X since tail-X already works for other items.

-Steve