Dealing with Autodecode

[Kirill Kryukov via Digitalmars-d]

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!!!!!!!!!!!!!!!!!!!!

This.

I only recently started full scale use of D, but I lurked here 
for years. D has a few quirks here and there, but overall it's a 
fantastic language. However the biggest putting off factor for me 
is the attitude of the leadership towards fixing the issues and 
completing the language.

The idea of autodecoding is very natural to appear for someone 
who only recently discovered Unicode. Whoa, instead of code pages 
we now have "unicode code points". Great. Only much later the 
person realizes that working with code points isn't always 
correct. So I don't blame anyone for designing/implementing 
autodecoding years ago. But. Not acknowledging that autodecoding 
is seriously wrong now, looks like a complete brain damage.

The entire community seems united in the view that autodecoding 
is both slow and usually wrong. The users are begging for this 
breaking change. There's a number of approaches about handling 
the deprecation. Even the code that for some reason really needs 
to work with code points will benefit from explicitly stating 
that it needs code points. But no we must endure this madness 
forever.

I realize that priorities of a language user might be different 
from those of a language leadership. With fixed (removed) 
autodecoding the user gets a cleaner language. Their program will 
work faster and is easier to reason about. User's brain cycles 
are not wasted for useless crap like working around autodecoding.

On the other hand, the language/stdlib designer now has to admit 
their initial design was sub-optimal. Their books and articles 
are now obsolete. And they will be the ones who receive 
complaints from the inevitable few upset with the change.

However keeping the current situation means for me personally: 1. 
Not switching to D wholesale, but just toying with it. 2. Even 
when using D for work I don't want to talk about it to others. I 
was seriously thinking about starting a D-learning seminar at 
work, and I still might, but the thought that autodecoding is 
going to stay is cooling my enthusiasm.

I just did a numerical app in D, where it shines, I think. 
However much of my work code is dealing with huge texts. I don't 
want to fight with autodecode at every step. I'd like arrays of 
chars be arrays of chars without any magic crap auto-inserted 
behind my back. I don't want to become an expert in avoiding 
language pitfalls (The reason I abandoned C++ years ago). I also 
don't want to re-implement the staple string processing routines 
(though I might, if at least the language constructs work without 
autodecode, which seems not the case here).

Think about it. 99% of code working with code points is _broken_ 
anyway. (In the sense, that the usual assumption is that code 
point represents a character, while in fact it does not). When 
working with code units, the developer will notice the problem 
right away. When working with code points, the problem is not 
apparent until years later (essentially what happened to D 
itself).

Feel free to ignore my non-D-core-dev comment. Even though I 
suspect many D users may agree with me. An even larger number of 
potential D users does not want autodecoding either.

Thanks,
Kirill