The Case Against Autodecode

[Andrei Alexandrescu via Digitalmars-d]

On 06/02/2016 11:38 AM, Adam D. Ruppe wrote:
> On Thursday, 2 June 2016 at 15:02:13 UTC, Andrei Alexandrescu wrote:
>> Yah, this is a bummer and one of the larger issues of our
>> community: there's too much talking about doing things and too
>> little doing things.
>
> We wrote a PR to implement the first step in the autodecode
> deprecation cycle. Granted, it wasn't ready to merge, but you just
> closed it with a flippant "not gonna happen" despite the *unanimous*
> agreement that the status quo sucks, and now complain that there's
> too much talking and too little doing!

You mean https://github.com/dlang/phobos/pull/4384, the one with "[do
not merge]" in the title?

Would you realistically have advised me to merge it?

I spent time writing what I thought was a reasonable and reasonably long
answer. Allow me to quote it below:

> @wilzbach thanks for running this experiment.
>
>> Andrei is wrong.
>
> Definitely wouldn't be the first time and not the last.
>
>> We can all see it, and maybe if we demonstrate that a migration
>> path is possible, even actually pretty easy following a simple
>> deprecation path, maybe he can see it too.
>
> I'm not sure who "all" is but that's beside the point. Taking a step
> back, we'd take in a change that breaks Phobos in 132 places only if
> it was a major language overhaul bringing dramatic improvements to
> the quality of life for D programmers. An artifact as earth
> shattering as ranges, or an ownership system that was massively
> simple and beneficial. For comparison, the recent changes in name
> lookup broke Phobos in fewer places (I don't have an exact number,
> but I think they were at most a couple dozen.) Those changes were
> closing an enormous hole in the language and mark a huge step
> forward. I'd be really hard pressed to characterize the elimination
> of autodecoding as enough of an improvement to warrant this kind of
> breakage. (I do realize there's a difference between breakage and
> deprecation, but for many folks the distinction is academic.)
>
> The better end game here is to improve efficiency of code that uses
> autodecoding (e.g. per the recent `find()` work), and to make sure
> `RCStr` is the right design. A string that manages its own memory
> _and_ does the right things with regard to Unicode is the ticket.
> Let's focus future efforts on that.

Could you please point me at the parts you found flippant in it, or 
merely unreasonable?

> When we do something, you just shut it down then blame us. What's
> even the point of trying anymore?

At some point I need to stick with what I think is the better course for 
D, even if that means disagreeing with you. But I hope you understand 
this is not "flippant" or teasing people then shutting down their good 
work.


Andrei