Dealing with Autodecode

[default0 via Digitalmars-d]

On Wednesday, 1 June 2016 at 01:36:43 UTC, Adam D. Ruppe wrote:
> D USERS **WANT** BREAKING CHANGES THAT INCREASE OVERALL CODE 
> QUALITY WITH A SIMPLE MIGRATION PATH!!!!!!!!!!!!!!!!!!!!

Agree with that very much.
Yes, you still have to think about cost/benefit for breaking 
changes, but in general when I sign up for D I expect it to throw 
out mistakes of the past so long as the correction of them is 
worth the cost of breakage.

So the cost of breakage for autodecoding is that the behaviour of 
roughly all string handling code changes. Now most of this string 
handling code was broken to begin with since VERY VERY VERY 
little string handling code ever cares about code points.
This means the code that is actually broken in terms of being 
buggy after the change when it wasn't buggy before is probably 
not a lot.
The other cost of breakage is to force a user to go through 
potentially thousands of LoC and update their string handling 
code. Personally, I find that cost dramatically reduced if there 
are two prerequisites met: Compiler Errors everywhere we have 
relied on the feature before (we can apparently do that, so 
check) and error/deprecation messages detailed enough to go into 
further reading so I can make meaningful decisions about it (we 
can also do that, I am sure, so check). If I just have to hop 
from one compiler error to the next and fix my broken code with 
confidence after having read about the context for 30-60 minutes, 
even going through vast amounts of code is not actually that big 
of a deal since you really only have to inspect a fraction of it 
(the fraction the compiler tells you about).
Another cost is if we have unmaintained 3rd party libraries, when 
we actually make the change the default in the future, they will 
stop compiling on recent compiler versions. I suppose a tool 
could be made tracking the specific compiler errors and simply 
using .byDchar to make the code "just work" exactly the way it 
used to work (ie unreliably, slowly and with bugs in string 
handling) before the change.

The cost of backwards-compatibility is also two-fold from what I 
can see:
-We will continue to be inefficient and waste time autodecoding 
by default (mobile users are going to be especially happy about 
that).
-By default, string handling code is still broken, just more 
subtly, meaning more string handling bugs in D code make it to 
production