Why ByChunk is not regnize by st.range.takeOne and why Section has no value

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, November 03, 2014 21:03:51 bioinfornatics via Digitalmars-d-learn wrote:
> Ok but I do not see why to use save method for a takeOne function
> is possible to write this function without to use it

It looks like the idea was that beacause you know that there's only one
element, you can make it random-access range with opSlice and popBack and the
whole shebang. And that works great if the range is at least a forward range,
but it currently falls apart with an input range, because while you can easily
emulate stuff like back and opIndex by forwarding it to front, save can't be
emulated so easily. So, either front needs to be accessed and saved in the
Result struct rather than than simply having it contain the range that it's
forwarding to, or it needs to have another branch of the static if for
handling input ranges separately. Though to be honest, I'm not sure that
using takeOne makes a lot of sense over take in that case. You don't really
get a performance boost, and since you can't add on the random-access range
capabilities without making it eager and saving the result of front (which is
an iffy thing to do with some input ranges), it's really not adding anything
over plain take. I'd honestly favor just fixing takeOne's template constraint
so that it checked for forward ranges. The only reason that I see to make
takeOne work with input ranges is simply so that no one will be surprised when
it doesn't work with an input range. But that's not really adding any useful
functionality as far as I can tell. Though maybe there's something that I'm
missing.

- Jonathan M Davis