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.
It will result in both path being half tested, code bloat, and many
algorithms that are unable to take benefit from the functionnality or
wouldn't work with regular ranges, because it don't fit the original
need of the dev.
What is exactly the problem with std.io.byLine ?
So, rather than just using consumeFront for any and all range types as would
be nice (but can't be done due to a few screwy ranges like ByLine - but such
is life), a range-based function which wishes to use consumeFront or
consumeBack will test with hasConsume whether the range that they're operating
on defines it (similar to what we do with hasSlicing for slicing). So, it
unfortunately will require special casing on the part of any function looking
to use consumeFront or consumeBack, but it _does_ allow us to operate on the
ranges which support it more efficiently if we decide to go to the effort of
special casing them.
It won't be done in many cases, and it more bug prone.
