Why do we have transitive const, again?

[Jonathan M Davis]

On Friday, September 23, 2011 22:24:37 Mehrdad wrote:
> Also, another problem I remembered about const:
> 
> If you have a const object, you can't have an invariant() that calls
> something impure (or something like that -- I forget the details, it was
> a while ago). Which was pretty darn annoying when I was trying to use
> D's DBC features, which seemed to again conflict with the the
> transitivity of const.
> 
> I'll post more issues as I remember them. There certainly wasn't just 1.
> 
> See below for inline reply.
> 
> -------------------
> 
> On 9/23/2011 8:08 PM, Jonathan M Davis wrote:
> > Many, many people _never_ try and lazy load or cache variables like
> > you're trying to do. So, there are many, many people that this will
> > never affect
> 
> Oh... was the purpose of D to appeal to /those/ kinds of people? If so,
> then please ignore this entire post; it was my mistake.

No. I'm saying that this particular issue is not an issue at all for many 
people. So, while this particular limitation of D's const may be annoying for 
some people, there are a _large_ number of D programmers that it will not 
impede at all, so for many programmers, it is not a showstopper issue at all. 
And for those where it _is_ a big issue, they have your choice of tradeoffs. Do 
they take the guarantees that D's const gives them and lose the ability to do 
lazy loading of member variables and caching of function return values in 
const objects, or do they not use const and lose the guarantees that it gives 
them but gain the ability to lazy load member variables and cache the return 
values of member functions? There are pros and cons to both choices. Making 
D's const intransitive provides an entirely different set of tradeoffs, and it 
was decided that based on D's design goals, transitive const was a better 
choice.

> > Obviously, it _will_ affect people but not enough that it would
> > cripple D's chances of catching on.
> 
> That's what we hope and keep our fingers crossed for, but something
> tells me that isn't quite enough. YMMV.
> 
> > Also, since all you have to do to work around the issue is to not use
> > const in this particular case (and there are already tons of
> > programmers who never use const and have no interest in it),and you're
> > fine, I don't see how this can be a showstopper for adopting the
> > language.
> "If it doesn't work then just don't use it"? I find it funny that you
> find this reasoning convincing, since I don't (and I don't think others
> do either).
> 
> > Yes, it's annoying, but there's a workaround which doesn't affect
> > performance at all,
> 
> Was const introduced for performance, or for code verifiability? I don't
> see how that's relevant, because honestly, the word "performance" wasn't
> even in my /mind/ when I was thinking about this problem. All I wanted
> was to _compile_ *verifiably correct* code, which failed pretty darn
> miserably, due to the const issues. I couldn't care less about
> performance when I was writing my code.

I mention performance, because a wokaround that reduces performance is 
generally considered a negative and is unacceptable to many. In this case, the 
workaround reduces verifiability, which is also a negative (and which appears 
to be the reason why you don't like it). But the very thing that you're trying 
to do goes against the compiler's ability to verify code correctness with 
regards to const, and making const intransitive would seriously reduce the 
compiler's ability to verify correctness in many other cases. In either case, 
you don't really have any fewer guarantees than C++ gives you, because C++'s 
const doesn't really give you much in the way of guarantees. At best, it helps 
you catch bugs where you accidentally altered a variable which you intended to 
not alter (so you made it const). That's a benefit to having const in C++, but 
since mutable and casting away constness can completely circumvent const in 
C++, you really don't get any verifiable correctness out of the deal. So, D 
lost the ability to give the relatively small benefit of finding cases 
accidental mutation when using lazy loading and caching in a class or struct 
but gained the ability to give strong guarantees which absolutely guarantee 
that a const variable is not modified in any way unless you circumvent the type 
system.

> > and if something like this is all it takes for you to decide that
> > you're not going to use a particular language, then it's going to be
> > hard to get you to use _any_ language.
> 
> I personally know that's not true, but why bother convincing you
> otherwise? Feel free to believe that, if it makes sense with your reasoning.
> > They _all_ have issues of one sort or another, if nothing else because
> > every language makes its own share of tradeoffs based on its goals.
> 
> NO! I think this is where you're missing the critical point. D's
> tradeoffs are NOT like other languages' tradeoffs.
> 
> Widely-used languages (C++, Python, C#, whatever) do NOT have half-baked
> (or even 95%-baked) features. They have features that work 100% of the
> time. Sure, they may be incomplete and they certainly have more room for
> improvement, but _what they *already* have_ works in EVERY situation. If
> you ever wondered what people meant on programmers.se when they said
> "C++ has a better thought-out type system", I hope you now know why.
> They did NOT mean that it has better features. Or that the compilers are
> of better quality. They were saying that the rules are self-consistent
> and they *work*. That is, _regardless_ of the compiler quality, the
> features of the *language* itself work in EVERY situation.
> 
> D, on the other hand, tries to appeal to everyone but instead has
> supposedly awesome features (e.g. transitive const) that DON'T work 100%
> of the time. They only work 95% of the time. You might refuse to believe
> this, but I'm convinced that this **IS** the reason why it's not being
> adopted as fast as you'd want it to be. You can continue to justify it
> as "but it works for 95% of people!" but the fact of the matter is that
> we've seen otherwise. Believe me, I want to see D get adopted too, but
> my brain is telling me that there HAS to be a reason it hasn't -- and
> that reason isn't the compiler bugs or anything of that sort, but the
> language itself.

_Every_ language has tradeoffs. A large number of the features in any language 
represent a tradeoff of some kind. I don't see why D's const is half-baked 
simply because it doesn't allow you to even fake logical const. I could just 
as easily argue that C++'s const is half-baked because it doesn't actually 
provide any real guarantee that a const value won't be changed.

D's const works precisely as it was designed to work. It gives strong 
guarantees about const values not being altered - which includes disallowing 
anything akin to logical const. It trades the ability to have lazy loading and 
caching in a const object in favor of those strong guarantees, whereas C++ 
allows the lazy loading and caching at the cost of those strong guarantees.

People complain all the time about features in other languages - especially 
C++. That does not make those languages (or D) half-baked or ill-thought out. 
In some cases, they have legitimate design mistakes. In others, it's a matter 
of tradefoffs and the fact that some design decisions in a language force other 
design decisions to go a certain way, even if that way may not be ideal.

I can understand that you don't like the fact that D's const does not allow 
for lazy loading or caching in a const object, but that does not necessarily 
mean that D's const as it stands was a bad design decision or that it needs to 
be changed. I think that it would be wonderful if we could find a way to 
introduce lazy loading and caching to const objects in D, but I do _not_ think 
that doing so at the cost of the strong guarantees that transitive const 
provides is worth it. Obviously, you feel differently. It's a tradeoff, and you 
prefer one of two sides, whereas I prefer the other.

- Jonathan M Davis