Dicebot on leaving D: It is anarchy driven development in all its glory.

[H. S. Teoh]

On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote:
[...]
> The reality is though, that D's const is not actually very useful, and
> C++'s const is.

Actually, I think C++ const is not very useful, because it guarantees
nothing. At the most, it's just a sanity checker to make sure the
programmer didn't accidentally do something dumb. But given an opaque
C++ function that takes const parameters, there is ZERO guarantee that
it doesn't actually modify stuff behind your back, and do so legally
(per spec).  I mean, how many times have you written const_cast<...>
just to get a piece of code to compile?  I know I've been guilty of this
in many places, because it simply isn't worth the effort to track down
all the places of the code that you need to fix to make it
const-correct.  So basically, C++ const is nothing more than an
annotation that isn't really enforced.

But you're spot on about D's const, though.  While D's const *does*
provide real guarantees (unless you tread into UB territory by casting
it away), that also limits its scope so much that it's rarely useful
outside of rather narrow confines.  Yet because it's so strict, using it
requires investing significant effort.  So you end up with the
unfortunate situation of "a lot of effort" + "limited usefulness" which
for many people equals "not worth using".


> D has no way to express head-const, and it turns out it's a
> tremendously useful concept.

I can live without head-const... but what *really* makes const painful
for me is the lack of head-mutable. I.e., given a const container (which
implies const objects), there is no universal way to obtain a mutable
reference to said const objects, unless you tread into UB territory by
forcefully casting it away.  This makes const so limited in
applicability that, for the most part, I've given up using const at all,
in spite of having tried quite hard to use it as much as possible for
years.


[...]
> I've also had occasional success refactoring to support const, but
> it's certainly the case that success is not guaranteed. And it's
> always time consuming regardless.

Yes, it's time-consuming.  And takes significant effort.  In spite of
being rather limited in applicability.  In my experience, it's useful
for isolated pieces of code near the bottom of the program's call chain,
where there is little or no additional dependencies.  But it's just too
cumbersome to use at any higher level, and a royal pain in generic code
(which I'm quite heavy on).  It probably *can* be made to work in most
cases, but it falls under my umbrella category of "too much effort
needed, only marginal benefits, therefore not worth it".


T

-- 
A linguistics professor was lecturing to his class one day. "In
English," he said, "A double negative forms a positive. In some
languages, though, such as Russian, a double negative is still a
negative. However, there is no language wherein a double positive can
form a negative." A voice from the back of the room piped up, "Yeah,
yeah."