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

[Yigal Chripun]

Simen Kjaeraas wrote:
> 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
why not? I only used const to simplify. you can add variant with the
same rules.
let's say that final defaults to const, BUT, if you can also use:
---
final invariant(C)  c= new C(); // a const ref to invariant data
---
since both mutable and invariant implicitly cast to const, the above is
sufficient. invariant data will contain invariant pointers only but
they'll convert to const whenever necessary.
also perhaps it's worth considering to remove the const T syntax from
the language and always require parens. it will simplify usage and
remove confusion for C++ programmers, because now both the syntax and
the semantics are different so you can't confuse the meaning of const T.


-- Yigal