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
