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
