Vision for the D language - stabilizing complexity?

[Walter Bright via Digitalmars-d]

On 7/15/2016 3:25 AM, Shachar Shemesh wrote:
> 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.

When we first introduced const to D, this was a common complaint. People were 
accustomed to the weaknesses of C++ const and misinterpreted it as a strength 
:-) But over time, D const won most over as being a better way, because it 
offered guarantees that C++ const simply does not.

For one, it enables function purity.


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

That's the same argument that appeared when we introduced transitive const.
But it means you can't do FP in C++. It means const doesn't work with generic 
types and generic algorithms. It means that const in a function signature tells 
you little to nothing unless it is applied to basic types.


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

Casting away const is only allowed in @system code. I agree that we need an 
improved definition of what happens when const is cast away in @system code, but 
in no case does it make things worse than in C++.


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

1. range checks - can be disabled by a compiler switch
2. memory allocation - D programmers can use any of C++'s allocation methods
3. default values - are removed by standard dead assignment optimizations, or 
can be disabled by initializing with '= void;'

There is one opportunity for C++ that D eschews: taking advantage of undefined 
behavior on signed integer overflow to improve loops:

   http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Practically speaking, optimizers are heavily built for and tuned for C++ 
semantics. Opportunities that arise due to the semantics of D are not exploited, 
but this isn't the fault of the core language and does not make C++ better.

Opportunities for D that are not available in C++:

1. making use of const
2. making use of immutable
3. making use of function purity
4. making use of asserts to provide information to the optimizer


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

I think your argument there is completely destroyed :-)