Overhauling the notion of output range

[Steven Schveighoffer]

On Mon, 12 Jul 2010 10:41:51 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 07/12/2010 07:44 AM, Steven Schveighoffer wrote:
>> On Mon, 12 Jul 2010 02:21:25 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 07/12/2010 12:45 AM, Philippe Sigaud wrote:
>>>> On Mon, Jul 12, 2010 at 03:17, Andrei Alexandrescu
>>>> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
>>>> 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