On Mon, 12 Jul 2010 10:41:51 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 07/12/2010 07:44 AM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 02:21:25 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 07/12/2010 12:45 AM, Philippe Sigaud wrote:
On Mon, Jul 12, 2010 at 03:17, Andrei Alexandrescu
<[email protected] <mailto:[email protected]>>
wrote:
In related news, there's been this burning desire regarding a
lightweight output range defined as simply a delegate that accepts
const(char)[]. That range is an output range all right, and the way
you output to it is by simply calling the delegate!
<http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L227>
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L227
It's still early where I live, but... For the callable case, why just
accepting E[] instead of any range with E as element? Though, thinking
about it, I right now have no idea how to put that into a template
constraint, given only R and E.
Hmm...
Good point. I haven't thought of it that way - I used arrays as a
lingua franca buffer. Your suggestion is interesting. I see a risk of
infinite regression in writing the constraint, but the idea warrants
more discussion.
Wait, isn't a delegate that accepts a type T an output range of type T?
Why does the argument have to be an array/range?
Efficiency - see the doFormat disaster.
Yes, I'm not saying that a delegate that accepts a range of T cannot be an
output range of T, I just wondered why it *has* to be a range.
For example, a delegate that accepts a string is a range of strings, is
it not? Or do you consider it a range of immutable(char)?
Good call. Probably I need to handle ranges of arrays differently. (The
problem has already come up, but I punted on it.)
It seems to me to be similar to appending -- you can append an element or
an array of elements. But appending the individual element makes sense in
a lot of cases, despite performance.
If output ranges were restricted to deal only with stream data (i.e. char)
then I'd agree only accepting an array of data is a good idea.
For example, I'd expect to be able to use a push_back delegate on an
array-type of integers as an output range.
Would it hurt to define push_back for arrays too? The thing is, if you
can output an array you can always output one occasional element. But if
you only know how to output an element, having the client side output
arrays in a loop can be quite slow.
If I always have to do something like this in order to append a single
element:
put(r, (&elem)[0..1]);
Then the concept of output ranges is much less attractive to me.
In some cases, appending a single element is all that works. For example,
a linked list could be an output range, and passing it an array is not
going to be any more optimal than passing individual elements.
-Steve
