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.
