Ranges of char and wchar

[Nick Sabalausky via Digitalmars-d]

On 5/8/2014 1:46 PM, Andrei Alexandrescu wrote:
>
> However output range means the string operation will be done eagerly,
> whereas lazy has advantages (nice piping, saving on work etc).

Isn't eagerness what we have array() for?

Also, while naming is often just bikeshedding, in this case I think we 
really need to address it. It's unfortunate that the new InputRange 
version can't be overloaded with the non-range version, because 
distinguishing them with "setExt" vs "setExtention" is just a non-option 
as far as I'm concerned.

But IMO that's the minor stuff, I think there's a bigger elephant in the 
room here:

The various benefits of doing it as an InputRange instead of 
OutputRange, combined with the terrible mess that resulted from 
converting such a straightforward function from OutputRange to 
InputRange is yet another clear indication that we REALLY need a 
coroutine-like/C#-like way to create InputRanges. Do we really expect 
simple algorithms exploding into messes like that to become the norm in 
D? I certainly hope not. I'd rather just go back to opApply.

I'm convinced this is a real problem for D moving forward, and I don't 
like continually seeing it get swept under the same "too unimportant for 
right now" rug as things that actually belong under there (like named 
parameters, ast macros, or pattern matching). Even C# is making us look 
really, really bad here, and C# can't even do generic code worth a damn.