On 3/6/2014 11:11 PM, Nick Sabalausky wrote:
What about this?:
Anywhere we currently have a front() that decodes, such as your example:
@property dchar front(T)(T[] a) @safe pure if (isNarrowString!(T[]))
{
assert(a.length, "Attempting to fetch the front of an empty array
of " ~
T.stringof);
size_t i = 0;
return decode(a, i);
}
We rip out that front() entirely. The result is *not* technically a
range...yet! We could call it a protorange.
Then we provide two functions:
auto decode(someStringProtoRange) {...}
auto raw(someStringProtoRange) {...}
These convert the protoranges into actual ranges by adding the missing
front() function. The 'decode' adds a front() which decodes into dchar,
while the 'raw' adds a front() which simply returns the raw underlying
type.
I imagine the decode/raw would probably also handle any "length"
property (if it exists in the protorange) accordingly.
This way, the user is forced to specify "myStringRange.decode" or
"myStringRange.raw" as appropriate, otherwise myStringRange can't be
used since it isn't technically a range, only a protorange.
(Naturally, ranges of dchar would always have front, since no decoding
is ever needed for them anyway. For these ranges, the decode/raw funcs
above would simply be no-ops.)
Of course, I just realized that these front()s can't be added unless
there's already a front to be called in the first place...
So instead of ripping out the current front() functions entirely, we
replace "front" with some sort of "rawFront" which the raw/decode
versions of front() can query in order to provide actual
decoding/non-decoding ranges.
