On Monday, 16 November 2015 at 06:24:05 UTC, Jonathan M Davis
wrote:
[...]
Regardless, I think that it's quite clear that certain idioms
simply do not work with physical const, and there's been
complaining about that for years. The only real question here
is whether those idioms are worth enough to lose out on
physical const. The answer up until now has always been no (at
least from Walter), but since Andrei is now hitting this
himself rather than seeing others complain about it, he clearly
views it as a problem in a way that he didn't before, so that
may result in him changing Walter's mind.
- Jonathan M Davis
I appreciate this discussion. I feel better that I am not the
only one having difficulty with the _const_ keyword. Honestly
about the only time I use _const_ is to tell the D compiler that
a struct member function does not modify its containing type.
When I start to use _const_ I quickly get a headache trying to
figure out how to fix my code when the compiler starts to
complain about function overloading issues and starts to require
explicit casts all over the place, _inout_ doesn't work, did I
use _Unqual_ or maybe I shouldn't, should this be a template,
etc. I end up with a headache and all I want is the thing to
compile. I wonder many times why go through the trouble. Why not
just use a unit test?
After reading through this discussion I wonder if it has been
considered to keep _immutable_ and _const_ as they are, but add a
less restrictive do-not-change-me type qualifier to the language?
A keyword like _readonly_, for example, could represent the idea
of intransitive const (or perhaps even a different type of
do-not-change-me-ness). I appreciate the need to be conservative
in language additions, especially at this point in the life cycle
of D2. Still, if people want and can show they need a type of
do-not-change-me type qualifier in addition to _const_ and
_immutable_ (not overlapping with unique et. al.) why not provide
it for them?
Just as a side thought, although it is probably a bit of a
dasoku. But I have always wondered that if the purpose of _const_
is to allow some data to be changed by one reference but not
changed by another, then why is it transitive. Doesn't that
defeat its purpose? And then doesn't transitive const effectively
have the same semantics and use-case as _immutable_? I mean, once
you start to use transitive const in an interface, how are you
supposed to get the mutable reference that is so promised?
Perhaps this is the question that is essentially being asked here?
Joseph
