08-Mar-2014 05:18, Andrei Alexandrescu пишет:
On 3/7/14, 12:48 PM, Dmitry Olshansky wrote:
07-Mar-2014 23:57, Andrei Alexandrescu пишет:
On 3/6/14, 6:37 PM, Walter Bright wrote:
In "Lots of low hanging fruit in Phobos" the issue came up about the
automatic encoding and decoding of char ranges.
[snip]
Allow me to enumerate the functions of std.algorithm and how they work
today and how they'd work with the proposed change. Let s be a variable
of some string type.
Special case was wrong though - special casing arrays of char[] and
throwing all other ranges of char out the window. The amount of code to
support this schizophrenia is enormous.
I think this is a confusion. The code in e.g. std.algorithm is
specialized for efficiency of stuff that already works.
Well, I've said it elsewhere - specialization was too fine grained.
Either a generic or it doesn't work.
Making strings bidirectional ranges has been a very good choice within
the constraints. There was already a string type, and that was
immutable(char)[], and a bunch of code depended on that definition.
Trying to make it work by blowing a hole in the generic range concept
now seems like it wasn't worth it.
I disagree. Also what hole?
Let's say we keep it.
Yesterday I had to write constraints like this:
if((isNarrowString!Range && is(Unqual!(ElementEncodingType!Range) ==
wchar)) ||
(isRandomAccessRange!Range && is(Unqual!(ElementType!Range) == wchar)))
Just to accept anything that works alike to array of wchar, buffers and
whatnot included.
I expect that this should have been enough:
isRandomAccessRange!Range && is(Unqual!(ElementType!Range) == wchar)
Or maybe introduce something to indicate any "DualRange" of narrow chars.
--
Dmitry Olshansky
