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
