Why can't we define re-assignable const reference variable?

[Yigal Chripun]

Yigal Chripun wrote:
> Janice Caron wrote:
>   
>> On 20/02/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
>>   
>>     
>>>  bound const Class c4 = new Class(); // bound (ie const) ref to const data
>>>     
>>>       
>> Wouldn't the word "const" be superfluous in that example, since
>> constancy is transitive? (If the reference is constant, the data
>> /must/ be).
>>
>> It's an interesting idea, but I think, in general, if the compiler
>> sees an array like
>>
>>     const(T)[] x;
>>
>> then it has to mean that the array's contents are not modifiable. That
>> rule shouldn't depend on T, it should simply be true always. Ditto all
>> other collections.
>>   
>>     
>
> As I've already said: it's only a start of an idea and should be further
> refined.
> that said, you are right that it's superfluous in the example above.
> I've mainly suggested a new keyword and the idea to seperate the two use
> cases of const.
> I'm not sure if the "bound" property should be transitive or not ( i
> suggested that it is but all options should be explored..) and it all
> depends on what semantics you want to achieve. maybe (probably) bound
> should also imply const on the referred data and const would imply all
> refs inside the data object to be bound.
>
> another tweak that can be done: intead of an error, if you apply bound
> to a value type (like a primitive) the compiler implicitly "casts" that
> to a const, that way you example above of an array would work for any
> type T. it could be used the same way in generic programming.
>
> --Yigal
>   
after thinking about the above here are my thoughts:
the problem is trying to apply a single rule to two very different
concepts, so either way you get some type of a compromise. so why not
just realize we have a duality in D and plan accordingly. thus instead
of the current rule which states:
for every type T, const(T) means that all of T is const and from it
derived the rule that const T = const(T)
and replace it with:
if T has value semantics (primitive, union, struct, enum, ..) than the
above rule applies.
else, T is a reference type (a class)  and const(T) means _only_ that
the instance data is const, and its reference is _not_.

what we get is that const(T)=const T only for value types.
now, instead of my proposed "bound" keyword, let's just use final which
is already a reserved keyword.
final will always imply const too because of const transitivity (it'll
be a superset of const). that way for value types the following are
identical:
const(S) s;
final S s;
final const S s; // could be reported by the compiler as redundant
const S s;
and for reference types (classes) we get the following behavior:
const(C) c = new C(); // mutable ref to const data
const C c = new C(); // same as above (compiler could issue a warning
for lack of parens)
final const(C) c = new C(); // const ref to const data
final const C c = new C(); //same as above
final C c = new C(); //same as above

no issues with const(int) being mutable and other unintuitive syntaxes.

generic programming - you can choose to use const(T)/const T for a
weaker input condition or a final T for a stronger input condition that
will enforce full constancy of T for all types.

for function definitions: 'in' should be mapped to const as defined
above, and as I suggested before the compiler should choose if he passes
the parameter by value or by reference with optional control of that by
the user (for system programming..)
also it could be worthwhile to make in the default.

D community - what do you think? am I totally wrong or is it a sane and
more powerful solution to const?

-- Yigal