mutable keyword

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, May 22, 2016 09:42:54 Jack Applegame via Digitalmars-d-learn wrote:
> On Saturday, 21 May 2016 at 21:49:23 UTC, Jonathan M Davis wrote:
> > Rebindable is in kind of a weird grey area. It involves a
> > union, not casting, and it's only ever mutating the class
> > reference, not the object itself. Certainly, if it mutated the
> > object, it would be undefined behavior, but it's just mutating
> > the reference - but then again, the type system itself doesn't
> > really differentiate between the two. So, I suspect that what
> > it comes down to is that Rebindable is doing something that you
> > really shouldn't, but because it's using a union rather than a
> > cast, and it's so limited in what it's mutating, its behavior
> > is effectively defined in the sense that the compiler has no
> > leeway, but's probably still technically undefined. I don't
> > know what Walter would say though. Certainly, if casting were
> > involved, it would be undefined behavior without question, and
> > it's not the sort of thing that you should be doing in your own
> > code.
> >
> > [...]
>
> I agree. But I think we need something that allows *logical*
> const and immutable.
> Strict binding constness to physical memory constancy is not
> always necessary and sometimes even harmful.

Actually doing logical const/immutable isn't really possible. Not even C++
does that. Rather, it provides backdoors that you can then use to implement
a sort of logical const, but there is zero guarantee that that's actually
what's happening. It's completely a matter of convention at that point. At
best, it would be possible to indicate that a portion of a type is const or
immutable while allowing certain parts of it to be mutable, in which case,
there are zero constness guarantees about the part that's always mutable and
no guarantees that the stuff that's mutable isn't part of the logical state
of the object.

Given how const and immutable work in D, having any portion of them be
treated as mutable, becomes highly problematic. It could theoretically be
done by having to mark such variables with an attribute and mark such types
with a similar attribute so that the compiler knows that the type in
question is not really following the rules of const or immutable and thus
doesn't make any assumptions about it like it would normally, but it risks
getting rather complicated, and Walter is most definitely not in favor of
such an idea. He is absolutely adamant that const is useless unless it's
fully const with no backdoors whatsoever. So, I'd be very surprised if any
kind of @mutable were added to the language. Certainly, you'd have to have a
very strong technical reason to convince him otherwise, and odds are that
he's just going to tell you to not use const, if it's not going to work for
the type to be const.

- Jonathan M Davis