Ranges of char and wchar

[Nick Sabalausky via Digitalmars-d]

On 5/8/2014 2:19 PM, H. S. Teoh via Digitalmars-d wrote:
>
> This way, you maximize the usability of the function -- it can
> participate in UFCS chains, compose with other std.algorithm functions,
> etc..
>

I think that actually raises an issue worth considering. I posit that 
the results of an InputRange setExtention don't make any sense with most 
std.algorithm functions:

What's an InputRange? It's a set of elements. So what are the "elements" 
of a setExtention? Uhh...

The result of setExtention really just has exactly one "logical" 
element: the resulting filesystem path. But that's not necessarily the 
*actual* result. The actual result is the "elements" of "however the 
hell setExtention's internal algorithm happened to feel like plopping 
them out". What are you going to zip() them, map() them, sort() them? 
All completely meaningless.

The "elements" of setExtention's InputRange are NOT defined. At least 
not in any well-encapsulated way. And really, they SHOULDN'T be defined.

So we have setExtention, and anything that follows it's model, returning 
what's more or less an undefined result that's basically useless for 
pretty much anything besides plopping straight into array() or copy().

If the big benefit of going InputRange instead of OutputRange for such 
functions is just simply call chaining, then maybe we're solving the 
wrong problem and should instead be looking at ways to improve the usage 
of OutputRange-based functions.