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
