Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

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.