Re: binary search with reference to append
- Posted by jimcbrown (admin) Jun 15, 2014
- 1598 views
I think that if we were writing this function for inclusion into the library now, we would not have these optional parameters. In hindsight, they are probably a poor design decision. But here we are ... we are stuck with them.
It seems perfectly reasonable to me, if everyone else agrees, to remove them. Of course that would be with a suitable entry in the release notes and both the manual and bsearch.e containing something like
Well, maybe. But this violates a Linus Torvald's maxim: We don't break user apis.
If it's in alpha or beta, then maybe. This made it to a bunch of 4.0.x releases, though.
Otherwise, the only time we chose to break this rule was with namespaces, and that was because we thought there was no way to make sane namespaces with the then-existing rules.
remembering to add 4 to abs(res).
Hmm, actually that's a good reason to keep it, same reason we have find_from()/match_from(). I always have trouble with that math when I have to do it myself.
Obviously, that is, if appropriate code changes to manage without them do not adversely affect the performance of next_prime().
I don't think we make a full shallow copy of a sequence (let alone a deep one) when we make a slice, so I doubt we'd see any performance issues here because of just this.
