The Case Against Autodecode

[ZombineDev via Digitalmars-d]

On Wednesday, 1 June 2016 at 19:52:01 UTC, Andrei Alexandrescu 
wrote:
> On 06/01/2016 03:07 PM, ZombineDev wrote:
>> This is not autodecoding. There is nothing auto-magic w.r.t. 
>> strings in
>> plain foreach.
>
> I understand where you're coming from, but it actually is 
> autodecoding. Consider:
>
> byte[] a;
> foreach (byte x; a) {}
> foreach (short x; a) {}
> foreach (int x; a) {}
>
> That works by means of a conversion short->int. However:
>
> char[] a;
> foreach (char x; a) {}
> foreach (wchar x; a) {}
> foreach (dchar x; a) {}
>
> The latter two do autodecoding, not coversion as the rest of 
> the language.
>
>
> Andrei

Regardless of how different people may call it, it's not what 
this thread is about. Deprecating front, popFront and empty for 
narrow strings is what we are talking about here. This has little 
to do with explicit string transcoding in foreach. I don't think 
anyone has a problem with it, because it is **opt-in** and easy 
to change to get the desired behavior.
On the other hand, trying to prevent Phobos from autodecoding 
without typesystem defeating hacks like .representation is an 
uphill battle right now.

Removing range autodecoding will also be beneficial for library 
writers. For example, instead of writing find specializations for 
char, wchar and dchar needles, it would be much more productive 
to focus on optimising searching for T in T[] and specializing on 
element size and other type properties that generic code should 
care about. Having to specialize for all the char and string 
types instead of just any types of that size that can be compared 
bitwise is like programming in a language with no support for 
generic programing.

And like many others have pointed out, it also about correctness. 
Only the users can decide if searching at code unit, code point 
or grapheme level (or something else) is right for their needs. A 
library that pretends that a single interpretation (i.e. code 
point) is right for every case is a false friend.