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
