Persistent list

[Dicebot via Digitalmars-d]

On Sunday, 15 November 2015 at 14:42:25 UTC, Jonathan M Davis 
wrote:
>> Casting away _const_ is already legal if programmer can 
>> himself guarantee underlying object has mutable origin (i.e. 
>> not available via immutable reference), by the very definition 
>> of const. It is casting away immutable and mutating that is 
>> strictly UB.
>
> No. As it stands, casting away const and mutating is _always_ 
> considered undefined behavior, regardless of whether the object 
> being referred to is actually mutable, const, or immutable. In 
> fact, there was a discussion on that not long ago, and the spec 
> was updated to be clearer on that count - with approval from 
> Walter. AFAIK, it has never been the case that casting away 
> const and mutating was defined behavior in D2 (I have no idea 
> what the deal with D1 and const is other than the fact that it 
> was quite different).

How was it justified to fit definition of `const`? It is in 
direct contradiction, because const is supposed to mean "can be 
either mutable or immutable, can't make any assumptions about it".

My understanding from previous discussions was that mutating 
const is UB is general because mutating immutable is UB and const 
_may_ be a view to immutable data. And if this can be proved to 
not be the case, const is not really const anymore. In fact, 
major chunk of our ported code relies on this.

(D1 is irrelevant here as const isn't a type qualifier there and 
this cant be part of cast)