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.
