mutable keyword

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, May 20, 2016 18:41:04 ciechowoj via Digitalmars-d-learn wrote:
> On Thursday, 19 May 2016 at 23:21:14 UTC, Jonathan M Davis wrote:
> > On Thursday, May 19, 2016 20:44:54 ciechowoj via
> >
> > Digitalmars-d-learn wrote:
> >> Is there D equivalent of C++'s mutable keyword? Like the one
> >> that allows to modify a field of struct from constant method.
> >> Or some alternative solution?
> >
> > Now, if your functions aren't pure, you can put state outside
> > of the object itself and have a const member function access
> > and mutate that external state, but that's not exactly great
> > for encapsulation, and then you can't use that function in pure
> > code. But it's the closest thing to a backdoor from const that
> > exists in D, because const is set up so that it's actually
> > const and not just const until the implementation decides to
> > mutate it anyway. Whether that's better or worse than C++'s
> > const depends on what you're trying to do, but the reality of
> > the matter is that D's const is ultimately very different from
> > C++'s const because of how restrictive it is. You get better
> > guarantees but can't use it anywhere near as much precisely
> > because of the restrictions that are required to provide those
> > guarantees.
> >
> > - Jonathan M Davis
>
> Thanks for explanation. It makes implementing things like
> shared_ptr somewhat troublesome when they are supposed to work in
> const environment. Isn't there a way to escape a pure environment
> (like trusted for safe)? Or/and would modifying an external state
> from pure function be an undefined behavior?

There is no backdoor for pure. You can cast it way via function pointer just
like you can cast away const, but it's then undefined behavior if you then
do anything in that function which wouldn't be legal in a pure function.

If you want something that's ref-counted and works in pure code, const will
_not_ work, because you can't legally alter the ref-count.

Now, Walter is currently working on language enhancements to add
ref-counting capabilities to the language, and presumably, that will have a
way around the problem for this particular use case, but when dealing with
const, you need to write your types such that they can work without being
able to mutate anything as long as they're const. And if your design
requires something like the mutable keyword, then you pretty much have to
give up on const. If you abandon pure, you can get around it to some extent,
but you're almost certainly better off if you just abandon trying to use
const if you can't refactor your code such that it doesn't need the mutable
keyword while still playing nicely with pure.

The net result is that while const can be use quite heavily in some types of
D code, it's often the case that it can't be used at all. This is
particularly true if you use templates heavily, since if they're templated
on type, you can't guarantee that the types being used play nicely with
const (at least not without having the template constraints require it) and
therefore usually can't use it. And ranges pretty much don't work with const
at all right now, since they can't be iterated over if they're const, and
there's not currently a way to get a tail-const slice of a range (even
though it works for arrays), so range-heavy code will definitely abandon
const.

So, while const is useful, its use is ultimately fairly limited.

- Jonathan M Davis