Constant relationships between non-constant objects

[Sebastian Unger via Digitalmars-d]

On Wednesday, 18 June 2014 at 03:36:54 UTC, Jesse Phillips wrote:
> On Wednesday, 18 June 2014 at 02:26:25 UTC, Sebastian Unger 
> wrote:
>> If so, what was the rationale to not include a feature in D 
>> that has been used with great success in other languages?
> D had 3 other const systems prior to its current state. This 
> system provided the needed guarantees with the least 
> complexity. Head-const would have added too much complexity for 
> the benefit (almost nothing).
Well, I think there is definitely benefit if you can tell the 
compiler that you don't mean to modify something and then the 
compiler will check this for you.
Just think bugs like
if (a = 3) ...
instead of
if (a == 3) ...
Not sure if this particular bug is possible in D, but that's 
beside the point.

>> I'd stronly argue for D getting that feature. If I can't 
>> express some of the most basic constructs in OOD in D
> Well, I always thought C++'s const was as described in this SO 
> response http://stackoverflow.com/a/2736231/34435
That link has one problem: It states that const means different 
things to different people. That's not quite correct. There are 
different things I want to be const in different situations and I 
need my language to be able to express ALL of these with ease. 
Sometimes I want an object in flash memory and immutable is 
needed. Sometimes I want to pass it around between threads and 
transitive const is really useful. And sometimes I want a 
relationship to be const and D can't express that. People are 
just used to expressing these different conccepts using different 
mechanisms depending on the language they're using. But for D to 
be truly superior to other languages it needs to be able to 
express at least the same as these other languages.

Basically what D is saying is, that every reference to an object 
from another object is a 'contains' relationship where transitive 
const makes sense. But that's simply not the real world of OOSD. 
In the real world there are many different types of relationships.

And yes, sometimes I want an object to be located in ROM but have 
a reference to another object in RAM that I can modify. No way to 
express this in D.


> "means this reference cannot be used to modify the instance"
> The problem being C++ did not enforce this rule and people 
> started abusing it. And now they can't live without it.
Hang on, that's not entirely true. True, you could cast away 
const (if that is what you are referring to), but you can do the 
same in D. Other than that C++ (and in fact even C) enforced 
constness perfectly well: Without a cast it is not possible to 
modify that which is declared const. True, C(++) could not 
express the concept of immutable to the point where the compiler 
can assume an object is not changing as D can. But C(++) could 
easily enough express const relationships which D cannot express.

Now, in the 19 years as a software developer, I have yet to come 
across a case where the (admittedly weaker) guarantees of C and 
C++ constness are simply not enough to express what I want to 
achieve. On the other hand, after beginning a small project as a 
test to see how D holds up, I came across the fact that D simply 
cannot express constant object relationships in a matter of hours.

So from my experience it is clear which concept is the more 
important (to the projects I've been working on at least). But 
both are valid!

So again, I believe, if D wants to play any role in major OO 
software design and development, it will need to step up its 
game. Especially in view of C++11 having addressed a number of 
the issues in C++ that I would have chosen D over C++ for.

Cheers,
Seb