Invariant doesn't apply to declared symbols

[Janice Caron]

> >   invariant(S) s;
> >   s = ...; //legal
>
> I thought Walter said we'd got rid of tail-const, and now there's just
> const? I thought that const(T) now meant that T is fully const?
>
> But you're right. The docs say otherwise. What's the deal?

I suppose there is still an issue which hasn't gone away, which is
this: Classes are passed by reference, so they are refence objects,
just like pointers. However, /unlike/ pointers, there's no existing
syntax to "dereference" them and refer directly to the bytes on the
heap. So there's an ambiguity, in that when you write

    const(C)

where C is a class, are you saying (a) the bytes on the heap are
const, or (b) both the reference, and the bytes on the heap, are
const? Clearly, my preference would be (b), since it seems so
/intuitive/ that const(T) must mean that T is const.

However, this does beg the question, is there a need for a syntax to
descibe (a)?

I suggest

    const(C.)

observe the dot after the C. To my mind at least, that clearly denotes
"members of", hence this means "members of C are const" (but the
reference itself is not).

That's not the only possible syntax, of course, and I don't want to
get hung up on it. The point is, it's an issue that hasn't been
properly addressed, and I believe it should be, if we are ever to
"unconfuse" const.