D const design rationale

[Walter Bright]

James Dennett wrote:
> Walter Bright wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>> In C++, sometimes const means invariant, and sometimes it means
>>>> readonly view. I've found even C++ experts who don't know how it works.
>>> Odd.  The C++ system always seemed extremely simple to me.
>> It isn't. 
> 
> It is to many people; you seem to have more experience with
> people who have trouble understanding it, maybe.

Many of these people are well known C++ experts (no, I won't name names 
<g>). It's a lot more complicated than it appears.


> I don't
> know why else it is that I find your diatribes about the
> terrible problems of C++'s const to be so strange, given
> that C++'s const works widely and well.

Probably because not many people realize that two well known 
shortcomings of C++, the alias optimization problem and the 
parallelization problem, are related to inadequacies of const.


> Maybe you're referring to the fact that some people don't
> learn that const means read-only in C++, rather than the
> "invariant" notion that you've introduced for D 2.0.

Yes. But sometimes C++ const means invariant, sometimes it means final, 
and sometimes it means readonlyview.

> That
> seems not to be hard for competent programmers to learn,
> compared to many of the other things they have to learn.

C++ programmers with many years experience often are surprised by this. 
C++ is a hard language to learn, and takes several years to master.


> (I'm concerned at using two synonyms to mean different
> things, but it's almost certainly too late to change
> that now.)

It's better than C++ using one word (const) to mean 3 different things, 
which is the root of why people are confused with what C++ const means.


>> Few understand when const is invariant and
>> when it isn't. I've never even seen anyone mention the problem where the
>> non-transitive const destroys any hope of having FP like capabilities in
>> C++.
> 
> And yet C++ *has* "FP-like" capabilities, depending on how
> we define our terms.

Not really. C++ has been pretty resistant to attempts to automatically 
parallelize code, and that's because of the weakness of const.

> Const works well in the hands of many, many C++ programmers.

For its limited application, yes. But rethinking the role of const can 
open the door to a lot more.

> Value, rather than reference, semantics are a great aid in
> providing FP capabilities in a manner that scales to parallel
> systems.  I'm glad to see that D is getting closer to C++ in
> providing more capable structs.

Invariant can provide value semantics with the performance of 
references. After all, you can't really pass a dictionary by value.

The other crucial bit is transitivity of const/invariant. In C++, you 
can say with const that you won't change the root of the dictionary, but 
you simply cannot specify that you won't change any nodes of it. Without 
that, you don't have FP. It's why people who want to parallelize C++ 
have to write extensions to the language to do it.

Writing extensions to C++, then implementing it as a translator that 
outputs C++, is a very difficult and expensive thing to do. People are 
not going to do it unless they can expect a very large return on their 
investment. This means they are trying to address a serious shortcoming 
of the language.

Based on this, I don't agree that C++ const is good enough for the 
future. It's a 20 year old design, and we can learn from it and do better.