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.
