On Sunday, 29 May 2016 at 17:35:35 UTC, Nick Sabalausky wrote:
On 05/12/2016 08:47 PM, Jack Stouffer wrote:
As much as I agree on the importance of a good smooth migration
path, I don't think the "Python 2 vs 3" situation is really all
that comparable here. Unlike Python, we wouldn't be maintaining
a "with auto-decoding" fork for years and years and years,
ensuring nobody ever had a pressing reason to bother migrating.
And on top of that, we don't have a culture and design
philosophy that promotes "do the lazy thing first and the
robust thing never". D users are more likely than dynamic
language users to be willing to make a few changes for the sake
of improvement.
Heck, we weather breaking fixes enough anyway. There was even
one point within the last couple years where something (forget
offhand what it was) was removed from std.datetime and its
replacement was added *in the very same compiler release*. No
transition period. It was an annoying pain (at least to me),
but I got through it fine and never even entertained the
thought of just sticking with the old compiler. Not sure most
people even noticed it. Point is, in D, even when something
does need to change, life goes on fine. As long as we don't
maintain a long-term fork ;)
Naturally, minimizing breakage is important here, but I really
don't think Python's UTF migration situation is all that
comparable.
I suggest providing an automatic tool (either within the compiler
or as a separate program like dfix) to help with the transition.
Ideally the tool would advise the user where potential problems
are and how to fix them.
If it's true that auto decode is unnecessary in many cases, then
it shouldn't affect the whole code base. But I might be mistaken
here. Maybe we should make a list of the functions where auto
decode does make a difference, see how common they are, and work
out a strategy from there. Destroy.
