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

[Steven Schveighoffer]

"Robert Fraser" wrote
> 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.
>>
>
> I wasn't aware of tat syntax. Please retract all comments I made in this 
> thread, this is exactly what I was looking for.

Hm... maybe true, but this is not the supported syntax for the current or 
future compilers, so you will be stuck at D 2.004 or something (can't 
remember which one).  Don't retract those comments just yet ;)

-Steve