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

Janice Caron caron800 at googlemail.com
Wed Feb 20 05:08:56 PST 2008


On 20/02/2008, Sergey Gromov <snake.scaly at gmail.com> wrote:
> This means that for int,
> which is not referencing anything,
>
> const(int) t;
>
> is completely and safely equivalent to
>
> int t;

Sergey, there may well be merit in the idea of having some form of
syntax which implies rebindable const classes. I'm not necessarily
against the idea. However, I most wholeheartedly /am/ against allowing
any kind of move which suggests that const(int) shall mean mutable
int!

One of the reasons that that syntax was ditched was because it was
damnably confusing, and got many, many complaints from people who were
using it. Not only did const(int) mean "mutable int", but even if you
could get your head round that one, it turned out that

    const (int *)* p;

and

    const (int **) p;

were completely equivalent. And I have absolutely no idea what the
syntax for array of const ints was. Was it "const(int)[]"? Was it
something else? I mean, it was just too confusing for words. No way
can we /ever/ go back to that. For any type, T, const(T) absolutely
/must/ mean that T is const.

So ... if you want widespread, across-the-board support for rebindable
class references, please, please, please choose a different syntax to
campaign for. Several syntaxes have been suggested in the past,
including

    const(T)& /* by me */
    ref const(T)
    const(*T)*
    tailconst(T)
    TailConst!(T)

and so on, any or all of which could work, if Walter finds a way to
make it possible. But not const(T). Anything else, just not const(T).



More information about the Digitalmars-d mailing list