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

[Steven Schveighoffer]

"Sergey Gromov" wrote
> Steven Schveighoffer wrote:
>> "Sergey Gromov" wrote
>> > Please, why invent new syntax ?
>> >
>> > const(T) t; // mutable ref to const T
>> > const{T t;} // const ref to const T, because of transitiviness
>> >
>> > This syntax even worked in one of the previous compiler versions!
>>
>> Yes, this is one of the trials of Walter to see if he could get 
>> tail-const
>> to work.
>>
>> The problem is if T is not a reference/pointer (such as int).  Now:
>>
>> const(T) t;
>> T t;
>>
>> are equivalent, which is necessary to make that const system work.  To 
>> have
>> some variable declared as const(T), and then allow assignment to that
>> variable is completely inconsistent with the fundamental usage of
>> parentheses.  If you have something defined as f(x), the entirety of x
>> should be affected by f.  This is why that system was dropped, as it 
>> should
>> have been.
>
> If you create a generic algorithm which works with T, and declare
> something as
>
> const(T) t;
>
> then you effectively assert that you're going to replace t with
> different other Ts, but promise to keep integrity of a referenced T
> intact, if anything is referenced at all.  This means that for int,
> which is not referencing anything,
>
> const(int) t;
>
> is completely and safely equivalent to
>
> int t;
>
> without breaking any contracts of your algorithm.  Please provide an
> example where "const(int) x;" absolutely must mean "const int x;" for a
> generic algorithm to work properly.

Sergey,  I am not arguing that the functionality that you wish to have is 
invalid.  In fact, I would have been ok with that syntax, and understood it 
once it was explained thoroughly.  But I have to say that I agree with 
Janice and Walter on this one, it was very confusing.

It just goes against the traditional usage of parentheses.  The idea is 
correct, the syntax is confusing.  Find another syntax.

-Steve