On Thursday, 9 October 2014 at 16:41:22 UTC, Andrei Alexandrescu
wrote:
Usage of output range is simply a generalization of out array
parameter
used in both Tango and our code. It is _already_ proved to
work for our
cases.
Got it. Output ranges work great with unstructured/linear
outputs - preallocate an array, fill it with stuff, all's nice
save for the occasional reallocation when things don't fit etc.
With structured outputs there are a lot more issues to address:
one can think of a JSONObject as an output range with put() but
that's only moving the real issues around. How would the
JSONObject allocate memory internally, give it out to its own
users, and dispose of it timely, all in good safety?
That's why JSON tokenization is relatively easy to do
lazily/with output ranges, but full-blown parsing becomes a
different proposition.
This reminds me of our custom binary serialization utilities,
intentionally designed in a way that deserialization can happen
in-place using same contiguous data buffer as serialized chunk.
It essentially stores all indirections in the same buffer one
after other.
Implementation is far from being trivial and adds certain usage
restrictions but it allows for the same extremely performant
linear buffer approach even with non-linear data structures.
In general I am not trying to argue that range-based approach is
a silver bullet though. It isn't and stuff like ref counting will
be necessary at least in some domains.
What I am arguing is that it won't solve _our_ issues with Phobos
(contrary to previous range-based proposal) and this is the
reason for being dissapointed. Twice as so because you suggested
to close PR that turns setExtension into range because of your
new proposal (which implies that efforts can't co-exist)
