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

[Janice Caron]

On 20/02/2008, Sergey Gromov <snake.scaly at gmail.com> wrote:
> Const only has meaning when applied to a reference.

Hardly. Const is perfectly meaningful when applied to a value!

> So:
>
>         const(T) x;     // tail const
>         const{T x;}     // full const
>
>  Simple.  Clean.

Yuk! Fortunately, I just don't believe Walter will go for that.

>  > Right now, in D2.011, "invariant(char)[]" is a string. That makes
>  > absolutely perfect sense. Long may that remain.
>
> Can't see any sense in making ptr and length variable.  This makes
>  strings 'somewhat const' to me.  Not really const.

Well then you really haven't understood it all. The characters of a
string may be stored in a ROM segment, and for that reason, the
characters of a string may not be modified. But there is no reason why
you can't modify slices which merely point into that ROM data.

Don't you see that "invariant(char)" means exactly that!? Chars that
are invariant - it doesn't get much simpler. And "[]" means "array
of". Hence, "invariant(char)[]" = "array of invariant chars".

If you want the array also to be invariant - no problemo! Just put the
array inside the brackets too - "invariant(char)[]".

I'm not describing anything exotic here - I'm describing the system as
it is now - simple, elegant, and obvious.


> Actually, const() syntax is already different from const attribute.

Again, you're wrong. The following two lines

    const int x;
    const(int)x;

are identical in meaning. And that remains true for any type, no
matter how complicated, e.g.

    const int[]* p;
    const(int[]*)p;

Again, completely identical. You are partly correct in that "const"
/when applied to member functions/ means something different, and that
is something which bugs me a little. But member functions aside, the
const attribute just makes things const, which is exactly what you'd
expect.

>  Probably if we had a tailconst attribute instead, so that it was
>  possible to write
>
>  tailconst
>  {
>         C c;
>         int x;  // either illegal, or not affected
>  }

That is something which no one has ever suggested before!

Oh, plenty of people have suggested tailconst, but it's generally
expected to be more along the lines of

    tailconst(C) c;


>  This should of
>  course deprecate the use of non-attribute const() form.

You can't! How could you declare

    const(int[][][])[][][] x;

without the brackets? (Not that I have a use for that particular type,
but hopefully you see the point).


> "tailconst S s;", which
>  in my syntax is "const(S) s;"

If you stop calling it const(S), I'll stop arguing with you. :-). I'm
still on the fence as to its utility, and Walter still says he can't
implement it, but if people want it, and Walter turns out to be wrong,
I certainly won't complain.


>  I see your main concern is educational.   This is resolved very simple,
>  too: teach that /everything/ in D are objects, and everything is by
>  reference.

Teaching lies is just plain wrong. D has both value type and reference types.