Article: Why Const Sucks

[ShadoLight]

Very interesting and well written! Jonathan, your experiences 
with const in C++/Java just about matches my experiences with it. 
I also feel that the situation in D is less than ideal in this 
regard.

First, a small (for sure copy-pasta) typo in your article:

const(int[]) arr1 = getArray();
const(int)[] arr2 = p1;  //Sure you meant arr2 = arr1;

Regarding the proposed solution to the issues with Object namely 
"the solution to this problem which was agreed to a few years ago 
was to remove opEquals, opCmp, toHash, and toString from Object 
so that derived classes can define them with whatever attributes 
are desired" which, you say, will never happen because of too 
much code breakage...

What about the following? Currently the compiler is smart enough, 
so you can define class Foo and explicitly inherit from Object if 
you prefer:
class Foo : Object {..} //OK, no recursive Object inherits Object 
ad-infinitum.

Would it not be easier to exploit this and go the "opposite" way 
i.e. rather than remove it, just extend the hierarchy by adding a 
base class to Object itself (in object.d no less), something like 
this:

class ObjectBase
{
     interface Monitor{..}

     static ObjectBase factory(string classname){..}
}


class Object : ObjectBase
{
     string toString(){..}
     size_t toHash() @trusted nothrow{..}
     int opCmp(Object o){..}
     bool opEquals(Object o){..}

     static Object factory(string classname){..}
}

Now, if you do:

class Foo{..} //OK. Still inherits from Object i.e. identical to 
'class Foo : Object {..}
class Foo : Object {..} //The same, just explicit
//On the other hand:
class Bar : ObjectBase //Deliberately bypass inheritance from 
Object.

Inheritance from ObjectBase will have to be explicit (the price 
to pay for non-breakage!), but now class Bar is free to implement 
opEquals, opCmp, toHash, etc as it sees fit. This still 
guarantees back-wards compatibility since all classes currently 
inherited from Object have exactly the same semantics as they do 
today. No upgrades to any current projects/code required!

Why was something like this not considered (you don't give a 
link, so I cannot investigate), rather than simply removing them 
from Object? Can this be exploited to, in effect, create the same 
opportunity but minus the breakage? Or am I missing something?

Actually, in a more general sense I have begun to wonder if the 
common point of departure in D-land, that the concept of 
tail-const is actually a "part of" the concept of const, is not 
maybe wrong. We typically describe the concepts of 
tail/head-const "in terms of" const i.e. const in D 'equals' 
head-const 'plus' tail-const [1]. Since the concepts of 
tail-const and head-const are not that well known (outside of 
mostly C++-land), these 2 concepts are often utilized to 
differentiate D's concept of const, and explain it relative to 
the const (or final/sealed/readonly/etc) found in other 
languages. Maybe that muddles the water, and the 3 concepts, even 
though related, can semantically exist separately as well!

I am of the opinion that we really need something like tail-const 
in D - particularly to semantically mark that the "payload" in a 
range is constant, but that the range itself can mutate. But it 
invariably falls apart when you try to shoehorn it into the 
general concept of const-ness in D with its transitivity 
properties, etc. The 2 concepts just don't gel, and I think the 
only way this can be accomplished is to have a separate semantic 
construct and syntax for tail-const. I think the 2 use cases are 
mostly orthogonal, and only overlapping in a narrow sense - but 
it this narrow sense that is used to explain it!. And, yes, the 
tail-const version will have less guarantees and none of the 
optimization opportunities that the current const version can 
promise.

Of course I realize the changes of this being added to D is 
practically zero; So, yes, i have to concur with your conclusions 
as well!

PS. BTW, your blog's title "The Long-Winded D Guy" is quite 
brilliant. You are indeed a bit long-winded, but you also take 
the time to explain things very thoroughly. It is a trade-off and 
I think in your case the cost-benefit ratio is positive. Thank 
you for that! Also, if you ever write a book (it might have to 
come in multiple volumes ;-), you can already count on having 1 
buyer!

[1] https://dlang.org/articles/const-faq.html#const