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
