On Friday, 15 July 2016 at 23:00:45 UTC, Walter Bright wrote:
On 7/15/2016 1:48 PM, Shachar Shemesh wrote:
On 15/07/16 22:50, Walter Bright wrote:
You can do logical const in D just like in C++, and get those
performance gains. You just can't call it "const". But you
can call it
/*logical_const*/ and get the same result.
No, you can't. The fact that the compiler enforces the no
const to mutable
transition (unless you use a cast)
The compiler does next to nothing - the maintainer can stick in
'mutable' members, and there's no reliable way to detect that.
The maintainer can stick in const removing casts, and there's
no reliable way to detect that, either.
If it's not mechanically checkable, it is not reliable, and is
what I call "faith-based programming."
is one of the main appeals of using const in
any language. If you call something "logical const", but the
compiler does not
help you to catch bugs, then I don't see the point.
I agree, and the C++ compiler is unable to verify "logical
const". It's entirely based on faith.
In effect, if logical const is what you want, C++ gives you a
tool while D
leaves you to your own devices. As a result, a lot of places
you'd define as
const in C++ are defined mutable in D, losing language
expressiveness.
You and I certainly have polar opposite opinions on that. C++
does not have a notion of "logical const" (it is not in the C++
Standard). It's an uncheckable convention, might as well just
use /*logical const*/.
D, on the other hand, has verifiable const and verifiable
purity.
D's const/immutable feature is powerful and I love it. I would
not trade it for C++'s version of const. It also seems fair to
say that const as C++ implements it, would not be worth adding to
D even if having two very similar features wasn't confusing.
After all, every feature starts with a negative score.
This subthread took it too far, that's the only reason I waded
in. C++'s const feature is not entirely useless.
Similarly:
If it's not mechanically checkable, it is not reliable,
I agree and I like mechanically checkable things. But I also like
compiler features that mix mechanical checking with the ability
to attest to something that can't be mechanically checked. Like
the @system attribute. So this line of reasoning feels incomplete
to me. Are we talking here about immutable/const only within the
context of @safe code? If so, then I missed that but I get it.
Otherwise, I don't get it.
