How does the community feel about having a "popFrontExactly" in
phobos?
"popFrontN" is like "take": Safe, but more costly: It double
checks there actually *are* "n" elements in the range, and if
not, stops pop-ing.
When using popFrontN, more often th
rsonally, 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 co
, 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
popFront
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 t
helper
library.
And I would call in popFrontExactly, not popFrontNExactly. The latter is
just hard to read and unnecessarily so.
On Friday, 23 November 2012 at 08:42:18 UTC, Jonathan M Davis
wrote:
I think that we'll probably need to add them in this case due
to efficiency
concerns, but it's not without cost. We don't want too many
stray functions
doing almost the same thing in Phobos.
- Jonathan M Davis
I'd say it's
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
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
n the long run,
> this makes "drop" *un*-safe...
I don't know if we can get away with it or not (given the possibility of
breaking code), but given that drop doesn't return how many elements were
popped (unlike popFrontN), I'd favor simply making it drop the exact numbe
I wouldn't mind also adding a popFrontApproximately()
=P
On Saturday, November 24, 2012 07:43:26 Mehrdad wrote:
> I wouldn't mind also adding a popFrontApproximately()
>
> =P
So, what's it do? Randomly pick a number close to the number that you give it
and try to pop that many? :)
- Jonathan M Davis
On Saturday, 24 November 2012 at 06:50:43 UTC, Jonathan M Davis
wrote:
On Saturday, November 24, 2012 07:43:26 Mehrdad wrote:
I wouldn't mind also adding a popFrontApproximately()
=P
So, what's it do? Randomly pick a number close to the number
that you give it and try to pop that many? :)
;
if they want popFrontExactly.
- Jonathan M Davis
Well, if the goal was reducing the amount of functions, or
avoiding hard to grasp variants, then I'd agree.
But in this case, the goal (IMO) is to provide convenient and
intuitive tools for coding.
I think (but this is my point of vi
13 matches
Mail list logo
