Ranges of char and wchar

[H. S. Teoh via Digitalmars-d]

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" <luis at luismarques.eu>" 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