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

[Simen Kjaeraas]

On Thu, 06 Mar 2008 20:21:32 +0100, Yigal Chripun <yigal100 at gmail.com>  
wrote:

> 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

First problem I see is that it does not take into account D's two types of
const - const and invariant.

-- Simen