Head Const

[Dicebot via Digitalmars-d]

On 02/17/2016 01:53 PM, Andrei Alexandrescu wrote:
> On 02/16/2016 09:44 PM, Walter Bright wrote:
>> On 2/16/2016 5:35 AM, Dicebot wrote:
>>> In my opinion @mutable would be a disaster of much higher destructive
>>> impact than head const. I am very opposed to it no matter how it is
>>> designed. Once you start considering it, you are better at simply
>>> throwing away existing const system and starting it all from scratch
>>> with D3. Logical const is harmful as it doesn't give and serious
>>> guarantees but gives developer a false sense of confidence.
>>
>>
>> I agree with you on that, and I've argued from that position before.
>>
>> Note that head const does not introduce any watering down nor
>> destruction of the const/immutable/sharing type system. The main
>> downside of head const would be language complexity.
> 
> I profoundly oppose such an outlook. It has a name - prejudice, pure and
> simple. Rejecting possible future ideas "no matter what" even before
> they exist is extremely damaging.
> 
> Consider:
> 
> "I oppose implicit narrowing conversions regardless how they are designed"
> 
> "static if is fundamentally flawed"
> 
> "Variadics cannot be both simple and safe"
> 
> etc.

It isn't that the concept of logical const / @mutable is inherently
flawed and I am rejecting any possibility of designing it decently. It
is the fact that it is quite alien to existing system and adding it will
inevitably be a hack of some sort.

Redesigning the whole thing with logical const in mind could be feasible
but is a bit too late. Retro-fitting into existing system is a different
thing though.

Consider "static if is fundamentally flawed" vs "static if is
fundamentally flawed [when applied to existing idiomatic C++ code]".
Former is opinionated prejudice. Latter can quite easily be true (even
if I personally wouldn't agree with it).