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
