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