The Case Against Autodecode

[Chris via Digitalmars-d]

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.