popFrontExactly?

Kapps opantm2+spam at gmail.com
Thu Nov 22 18:55:21 PST 2012


On Thursday, 22 November 2012 at 13:08:56 UTC, Jonathan M Davis 
wrote:
> On Sunday, November 18, 2012 21:34:37 monarch_dodra wrote:
>> Should I push a pull request adding such a function (and its
>> friends) to phobos? How does the group feel about such 
>> functions?
>
> In principle, it's a good idea, but I also worry about a 
> proliferation of such
> functions. Personally, I think that I would have argued for 
> popFrontN being
> popFrontExactly in the first place, but it's obviously too late 
> for that. In
> probably all cases that I use popFrontN, what I'd want would be
> popFrontExactly (though popFrontNExactly would probably be a 
> better name given
> its connection to popFrontN).
>
> So, you probably should create a pull request for it, but then 
> you need
> popBackNExactly too, and possibly drop(Front)Exactly and 
> dropBackExactly, and
> that's where things get a bit ugly. But given the concerns for 
> efficiency and
> the prevalence of functions like popFrontN in range based code,
> popFrontNExactly would make good sense.
>
> - Jonathan M Davis

Is it really that big an issue to have a few more methods than 
standard ranges would need? Before it certainly would be annoying 
to have to check if the range supported it, use that, and if not 
fake it, but now we have UFCS. It would be simple to have a basic 
fallback implementation of methods such as popFrontExactly, then 
simply use range.popFrontExactly to get the more performant one 
if the range supports it, and if not get the fallback.

It would have to be clear in the documentation that these are 
optional methods however, and are recommended only if performance 
is required (and if the range supports it in a way that isn't 
simply an alternate implementation of the fallback).


More information about the Digitalmars-d mailing list