On 9/8/18 8:36 AM, Steven Schveighoffer wrote:
On 8/9/18 2:44 AM, Walter Bright wrote:
On 8/8/2018 2:01 PM, Steven Schveighoffer wrote:
Here's where I'm struggling -- because a string provides indexing,
slicing, length, etc. but Phobos ignores that. I can't make a new
type that does the same thing. Not only that, but I'm finding the
specializations of algorithms only work on the type "string", and
nothing else.
One of the worst things about autodecoding is it is special, it *only*
steps in for strings. Fortunately, however, that specialness enabled
us to save things with byCodePoint and byCodeUnit.
So it turns out that technically the problem here, even though it seemed
like an autodecoding problem, is a problem with splitter.
splitter doesn't deal with encodings of character ranges at all.
For instance, when you have this:
"abc 123".byCodeUnit.splitter;
What happens is splitter only has one overload that takes one parameter,
and that requires a character *array*, not a range.
So the byCodeUnit result is aliased-this to its original, and surprise!
the elements from that splitter are string.
Next, I tried to use a parameter:
"abc 123".byCodeUnit.splitter(" ");
Nope, still devolves to string. It turns out it can't figure out how to
split character ranges using a character array as input.
Hm... I made some erroneous assumptions in determining these problems.
1. There is no alias this for the source in ByCodeUnitImpl. I'm not sure
how it was working when I tested before, but byCodeUnit definitely
doesn't have it, and doesn't compile with the no-arg splitter call.
2. The .splitter(" ") does actually work and return a range of
ByCodeUnitImpl elements.
So some of my analysis must have been based on bad testing.
However, the issue with the no-arg splitter is still there, and I still
think it should be fixed.
I'll have to figure out why my specialized range doesn't allow splitting
based on " ".
-Steve
