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.
