Why not flag away the mistakes of the past?

[Chris]

On Friday, 9 March 2018 at 06:14:05 UTC, Jonathan M Davis wrote:

>
> We'll make breaking changes if we judge the gain to be worth 
> the pain, but we don't want to be constantly breaking people's 
> code, and some changes are large enough that there's arguably 
> no justification for them, because they would simply be too 
> disruptive. Because of how common string processing is and how 
> integrated auto-decoding is into D's string processing, it is 
> very difficult to come up with a way to change it which isn't 
> simply too disruptive to be justified, even though we want to 
> change it. So, this is a particularly difficult case, and how 
> we're going to end up handling it remains to be seen. Thus far, 
> we've mainly worked on providing better ways to get around it, 
> because we can do that without breaking code, whereas actually 
> removing it is extremely difficult.
>
> - Jonathan M Davis

It's aleady been said (by myself and others) that we should 
actually try to remove it (with a compiler switch) and then see 
what happens, how much code actually breaks, and based on that 
experience we can come up with a strategy. I've already said that 
I'm willing to try it on my code (that is almost 100% string 
processing). Why not _try_ it, later we can still philosophize