Dealing with Autodecode

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 2 June 2016 at 04:42:49 UTC, Walter Bright wrote:
> Andrei is in favor of fixing Phobos so it does not depend on 
> autodecode.

Putting the autodecode functions on a compiler switch (with 
-version) is the most straightforward way to achieve that.

We'd have a transition period where people can keep the existing 
behavior or throw the switch and get compile errors - with a 
dead-simple "just add .byCodePoint on this line" fix - to migrate 
their code.

Phobos would be fixed in a day. Everyone else would have up to a 
couple years to fix their code (which, again, is as simple as 
throwing a compiler switch and mechanically adding .byCodePoint* 
where the static asserts tell you to) as we work through the slow 
deprecation cycle.

But then, we'd have light at the end of the tunnel: after this 
deprecation cycle completes, we can kill hundreds of lines of 
confusing, worthless functions. Existing functions that don't 
work with ranges of chars will be able to without trouble. 
Newbies will never again ask "wtf" when they see string.whatever 
yielding dchar[].

* Or byGrapheme or .byCodeUnit or whatever if you want to take 
the time to actually fix the fundamental question of the code, 
but just slapping .byCodePoint in there reverts to the same 
behavior of autodecode.

> Interestingly, when I tried to remove autodecoding from 
> path/file code a couple years ago, I received quite a bit of 
> resistance. It seems there's been a tectonic shift in opinion 
> on autodecode.

Quite a few of us were incompetent ignoramuses on the topic of 
Unicode years ago. That's where the autodecoding mistake came 
from: people smart enough to know UTF-8 from UTF-32, but not 
smart enough to know the real world application of Unicode.

It's one thing to make a mistake. Everyone does that sometimes, 
and nobody is born knowing complex issues. What matters is if 
you're willing to learn new information and correct your errors.