Overhauling the notion of output range

[Andrei Alexandrescu]

On 07/12/2010 09:59 AM, Steven Schveighoffer wrote:
> 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]);

No, the library does that. Look here:

http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/range.d#L306

Andrei