Proposal: takeFront and takeBack

[deadalnix]

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.