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

[Manu]

On Tue, 28 Aug 2018 at 10:54, H. S. Teoh via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> 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.

I'd rate that as "pretty damn useful"™!

> 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).

Well it can't modify the head-object... that's the point of head-const!

> I mean, how many times have you written const_cast<...>
> just to get a piece of code to compile?

Never in my life. That's a heinous crime. If it were removed from C++
and declared UB, I'd be fine with that.

> 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.

It could be enforced though. const_cast<> doesn't have to exist, and
`mutable` doesn't have to exist either.
That would strengthen C++'s design to make it more meaningful while
retaining a generally useful semantic.

That said, D's transitive const is a nice thing to be able to
express... I just recognise that it's mostly useless, and from that
perspective, I think being able to express the C++ meaning would be
useful, and certainly MORE useful.
I wonder if there's a design that could allow to express both options
selectively?

> 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".

And then that case of not being used (even if it could have) blocks
use somewhere else, and not(/unable-to)-const spreads like a virus >_<

> > 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,

... I think we're talking about the same thing.
In this context, the container is the 'head', and the elements would
be mutable beneath that unless declared const themselves.

> 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.

Right. This appears to be the accepted recommendation for quite some
time, and no change in sight.
Tragically, the more people resign to this recommendation (and it's
practically official at this stage), the harder it becomes to use even
if you want to; any library code that you interact with that didn't
use const because 'recommendation' creates interaction blockages for
your own code, propagating can't-use-const into your client code,
despite your best intentions.

D's const is an objective failure. I don't think anyone could argue
otherwise with a straight face. It's sad but true; the surface area
and complexity of the feature absolutely doesn't justify its limited
(and actively waning) usefulness.