Vision for the D language - stabilizing complexity?

[Shachar Shemesh via Digitalmars-d]

On 15/07/16 13:13, Walter Bright wrote:

> 1. no protection against casting away const and changing it anyway
> 2. no protection against adding 'mutable' members and changing it anyway
> 3. only good for one level, no way to specify a data structure of
> generic type T as const
>
>> (and, sadly, not something D does very well)
>
> Explain. D fixes C++ faults 1..3.
>

Yes, it does. And the result is that const is well defined, safe, and 
completely impractical to turn on. There are many many places I'd have 
the compiler enforce const correctness in C++, where in D I just gave 
up. In one of those places we even went as far as to add run time checks 
that no one inadvertently changed a buffer.

I think the one that hurts the most is fixing "C++ fault" #3. It means 
there are many scenarios in which I could put const in C++, and I simply 
can't in D, because something somewhere needs to be mutable.

Check this thread out to see that we actually do need something like #1 
in D (though, at least if my suggestion is accepted, without throwing 
away the optimizations it allows).

>
>> In terms of optimizations, there are, indeed, cases where, had const
>> not been
>> removable, things could be optimized more. I don't think D has a right to
>> complain about C++ in that regard, however.
>
> Of course D does. I had to disable const optimizations in my C++
> compiler, which is one of the motivations for the way const works in D.
>

For const, yes. In almost every other aspect of the language, however, D 
favors safety over performance. Just look at range checks, memory 
allocation, default values, and those are just the examples off the top 
of my head.

I'm not saying that as a bad thing about D. It is a perfectly valid and 
reasonable trade off to make. I'm just saying D has no right to 
criticize C++ for missed optimizations. People who live in glass houses 
should not throw stones.

Shachar