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

[Yigal Chripun]

Janice Caron wrote:
> On 09/03/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
>   
>>  also perhaps it's worth considering to remove the const T syntax from
>>  the language and always require parens.
>>     
>
> The bad news is, that would also disallow
>
>     const x = 3;
>
> and
>
>     const
>     {
>         int x = 3;
>         int y = 4;
>     }
>
> The problem here is that "const" is an "attribute" in the grammar, and
> therefore can be used anywhere "public", "static", "auto",
> "version(X)", and so on can be used. Changing that would be a major
> upheaval.
>
> The simplest route to re-assignable const reference is probably a
> template solution. In fact, if you look at the change log for D2.012,
> you'll see that it says: "std.typecons: added undocumented Rebindable
> in preparation for opImplicitCast." So, that sounds to me like as the
> language permits (as soon as we have opImplicitCast) we'll also have
> Rebindable!(T) - a rebindable class reference. We just need to hang on
> a little bit longer.
>   
since all programming languages are Turing complete you can write code
to emulate what ever you want. With that line of thought you don't need
const as part of D either, as you can write template code to emulate
that feature. yet, it is in the D language. the point is, that while
Rebindable!(T) will solve the problem from an implementation point of
view, it still remains a hack IMHO that shows a lacking type system.
the fact that you can solve it with a template doesn't mean that it's a
better, cleaner design, and while taste is a personal thing, for me that
makes D look ugly and unpolished.
Walter's enum solution to the manifest constant is a similar issue,
while it does solve the problem, it remains IMHO an ugly hack.

all I wanted to point out is that i want a more elegant solution, and
that sometimes implementation driven design makes for bad decisions.
while manifest constants and enums probably should have the same
implementation (for example), that does not imply that the interface
should be the same too.
</rant>

--Yigal