On Thu, May 08, 2014 at 02:38:18PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: > On 5/8/14, 1:41 PM, "Luís Marques" <[email protected]>" wrote: > >On Thursday, 8 May 2014 at 18:21:32 UTC, H. S. Teoh via > >Digitalmars-d wrote: > >>I've thought about input ranges vs. output ranges for a bit. I > >>think it doesn't make sense for functions that process data to take > >>an output range: output ranges are data sinks, and should only be > >>used for the endpoint of a data processing pipeline. Since the > >>string function doesn't know whether or not it's the last in a > >>pipeline (only the calling code can know this), it should return an > >>input range. If the user code wants to put the result into an output > >>range, then it should simply use std.algorithm.copy. > > > >I agree with H. S. Teoh. Indeed, I was thinking of trying to create > >an alternative version of std.format which returned an InputRange, > >instead of taking an OutputRange. The benefit of this becomes obvious > >when you want to use std.format() in your own ranges, which currently > >impairs laziness, pipelining, avoiding memory allocations, etc. > > Interesting. So then the range returned by format() will save > everything passed to it, which means... > > int fun(int[] a) > { > auto before = format("Before: %s", a); > foreach (ref e; a) ++e; > auto after = format("After: %s", a); > writeln(before, "\n--->\n", after); > } > > *ouch* [...]
Yeah, I'm not so sure it's a good idea for std.format to be lazy. But there are valid use cases for both, so now I'm wondering if we should adopt Walter's idea of using a naming convention to distinguish between algorithms (lazy) and functions (eager). T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan
