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