Ranges of char and wchar

[John Colvin via Digitalmars-d]

On Thursday, 8 May 2014 at 17:46:06 UTC, Andrei Alexandrescu 
wrote:
> A discussion is building around 
> https://github.com/D-Programming-Language/phobos/pull/2149, 
> which is a nice initiative by Walter to allow Phobos users to 
> avoid or control memory allocation.
>
> First instance of the pull request copied the inputs into an 
> output range.
>
> The second instance (right now) creates an input range that 
> lazily creates the result. The element type of that range is 
> the encoding type of the first argument (i.e. char or wchar 
> most of the time). This is different from string/wstring/etc 
> element-wise iteration because it'll be done code unit-wise, 
> not code point-wise.
>
> We need a robust idiom for doing such string manipulation 
> without allocation, for which setExtension is just an example. 
> Going the output range route has nice things going for it 
> because the output range decides the encoding in advance and 
> then accepts via put() calls any encoding, with only the 
> minimum transcoding needed.
>
> However output range means the string operation will be done 
> eagerly, whereas lazy has advantages (nice piping, saving on 
> work etc).
>
> On the other hand, there's the risk of becoming "more catholic 
> than the Pope" by insisting on lazy string processing. Most 
> string operations are eager, and insisting on a general 
> framework for lazy encoded operations on strings may be an 
> exaggeration.
>
> D{iscuss,estroy}!
>
>
> Andrei

A little thing I've been thinking about on a related note:

someOutputRange <| someInputRange;

equivalent to

someInputRange |> someOutputRange;

which is conceptually the same as

someInputRange.copy(someOutputRange);

perhaps implemented by introducing new operators opSink (in the 
output range) and opSource (in the input range). These would be 
invoked as a pair, opSource returning an input range which is 
passed to opSink.

If not implemented, opSource defaults to `auto opSource() { 
return this; }` or even `alias opSource = this;`. opSink would 
default to a std.algorithm.copy style thing (can't really be 
std.algorithm.copy itself because you don't want the dependency).

I'm not sure what ground this really breaks, if any, but it sure 
looks nice to me.