Dealing with Autodecode

[Chris via Digitalmars-d]

On Thursday, 2 June 2016 at 13:34:18 UTC, Adam D. Ruppe wrote:
> 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.
>

I would love to have a compiler switch and finally be able to rid 
my code of auto decoding [1], once and for all - and get a free 
performance boost. There's so much talk about code that _might_ 
break, when we don't even know how much code would actually 
break. It's absurd, we remain inert out of fear of the unknown, 
while it would be pretty easy to just test it and find out 
(std.path is actually a precedence). And it wouldn't even be a 
breaking change in the sense that you cannot go on developing 
with D's latest version because you're stuck with a stone age 
version of dmd forever.

Much in the same vein, I don't know, if we should make the 
question of auto decode dependent on RCString. This will take at 
least another few months of bikeshedding, while what we need to 
do is get rid (or start to get rid) of auto decode right now - 
and maybe this process will teach us something that will later be 
useful when implementing RCString.

[1] As I already mentioned here
http://forum.dlang.org/post/yzeiqvphrqdcmaxaspvx@forum.dlang.org

[snip]