The Status of Const

[Steven Schveighoffer]

On Mon, 16 Aug 2010 10:58:52 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> Hopefully, Andrei will eventually get around to dealing with const in  
>> std.container and see what a mess it will become without some sort of  
>> tail-const for ranges.
>
> I believe at some point an approach will come forth. Here are a few  
> quick thoughts on this large exchange:
>
> * I think head-const has its usefulness, and tail-const is obviously in  
> need for serious attention. Ideally we should reach, with no or minimal  
> language changes, the point at which full const is the built-in power  
> tool and head-const and tail-const are library artifacts. I think it's  
> quite easy to define a Final!T template that is head-const, and  
> Rebindable!T is a starting point for tail-const classes. We need to  
> figure a pattern for achieving tail constness for general types.

Tail-const is already not a library solution.  A tail const pointer or  
array is possible without library support.

If a solution can be had via a library, it must still enjoy some compiler  
support for implicit casting.  It must also avoid any undue extra code  
generation.  Const is purely a compile-time feature, it plays no role in  
the eventual generated code.  It simply prevents cases which the developer  
has asked it to prevent.

> * Const and immutable will be used less often than in C++. This might  
> seem a weakness to those coming from C++ where const can and should be  
> sprinkled often, but it is a natural consequence of the relative  
> restrictions imposed by const in C++ vs. D. D's const is more  
> restrictive, and as such will find its way in fewer idioms than C++'s.

Currently, object is very const incorrect.  Once it becomes const-correct,  
I think this observation may drastically change.  But more importantly,  
many pieces of phobos/druntime simply don't work with const (dup/idup  
comes to mind).  It may not be a case that const isn't required, but more  
that const can't be correctly implemented without incurring lots of code  
duplication.  So we all "put off" making things const correct until const  
is fixed.  Observing that D currently isn't full of tail-const references  
may be an artifact of that problem.

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

-Steve