casting away const and then mutating

[Jonathan M Davis via Digitalmars-d]

On Friday, 24 July 2015 at 20:44:44 UTC, Steven Schveighoffer 
wrote:
> The advantage of simply clarifying the spec is that the current 
> compiler behavior (which should work) doesn't need to change, 
> we just change the spec.
>
> Ideally, we should just fix the situation with tail-const and 
> we could have the best answer.

Yeah. That needs to be fixed. As I understand it, it's feasible 
without any language improvements, but it's horrific. Jonathan 
Crapuchettes talked at one point about doing it at EMSI (and how 
hard it was). The last time I tried it, I ran into problems with 
recursive template definitions, though static if can probably 
solve those.

Regardless, the situation with it is ugly and not well 
understood, even if there is a solution, and ideally, we'd find a 
way to implement it that was a lot easier and cleaner. Without 
that, almost no one is going to be doing it - probably even if 
there's an article on dlang.org explaining how - simply because 
of how annoying it is to do.

> I think I'll give up on this argument. There isn't much use in 
> putting in a rule for the spec that covers over a missing 
> feature that we will likely add later.
>
> Also, I just thought of a better way to do this that doesn't 
> require any casting.
>
> Forget this thread ever happened :)

Well, regardless of whether mimicking inout like we're talking 
about with RedBlackTree should be considered defined behavior or 
not, I think that the spec should be updated so that the 
situation is clearer. It needs to be clear to the community at 
large that you _cannot_ be casting away const and mutating simply 
because you know that the data is mutable underneath rather than 
immutable.

- Jonathan M Davis