Proposal: takeFront and takeBack

[Dmitry Olshansky]

On 04-Jul-12 14:50, deadalnix wrote:
> Le 04/07/2012 06:32, Jonathan M Davis a écrit :
>> Okay, given the fact that takeFront wouldn't work with ranges like
>> std.stdio.ByLine, the code as proposed won't work. So, here's an adjusted
>> proposal:
>>
>> https://github.com/jmdavis/phobos/commit/14b88d9d5528f8736ae6014013bba82367e83620
>>
>>
>> As suggested, I renamed takeFront and takeBack to consumeFront and
>> consumeBack
>> respectively, but now they're in std.array and only apply to arrays.
>>
>> hasConsume has been added to std.range and tests whether a particular
>> range
>> defines consumeFront (and if it's a bidirectional range, whether it
>> defines
>> consumeBack).
>>
>
> I don't think this is a good idea. Now many algorithms will have to be
> split in several versions.
>

I have another idea though it's intrusive.
How about broadening definition of Input/Forward/Bidir range? (take a 
look at OutputRange it supports a ton of interfaces).

Let's define a new class of volatile ranges.
That is the ones where fron/popFront are just one op and then interface is:
struct InputRange{
	@property T getFont(); //or consumeFront or readFront
	@property bool empty();
}

Forward is the same + save
Bidir also has getBack/consumeBack.

What I see good about it is that now you can't make low-performance code 
out of it just by using wrong calls.

Now what to do with algorithms & foreach...

calls front/popFront should be rewritten:
1st one :
for(tmp=r.front;!r.empty;r.popFront())

2nd one :
while(!r.empty, tmp=r.getFront)

Rewrite in all other cases would involve putting
x.front --> temporary local, that is 'cache' results of getFront.
dunno how to get it cleanly & auto-magically.
(though one way is to use static TLS variables as cache it's... dirty)

-- 
Dmitry Olshansky