Re: [RFC] intdiv()

On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters <tjerk.meesters@gmail.com> wrote: > > > > On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig <kris.craig@gmail.com> wrote: > >> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds <ajf@ajf.me> wrote: >> >> > >> > On 17 Jul 2014, at 10:24, Nikita Popov <nikita.ppv@gmail.com> wrote: >> > >> > > This is already what is currently happening, see >> > > >> > > http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. >> > > >> > > Andreas proposal is only useful in the case that the numbers don't >> divide >> > > exactly and you need round-down/truncation behavior and your numbers >> are >> > in >> > > a range where the indirection through double arithmetic results in >> > > precision loss. >> > >> > It’s still useful regardless as it saves you implementing it in terms of >> > floats. >> > >> > I mean, you can implement a right shift (rarely used outside bit masks) >> in >> > terms of multiplication and exponentiation, but that doesn’t mean you >> > shouldn’t have a right shift. >> > >> > -- >> > Andrea Faulds >> > http://ajf.me/ >> > >> > >> > >> > >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> There seems to be a pretty even split on this. Personally, I'm a +1 for >> it. PHP has tons of obscure, rarely used functions. Even if the gain is >> relatively minor, there's really no cost that I can think of. So from a >> cost-benefit standpoint, even a minor improvement is still desirable when >> there's no practical downside to it. >> >> Given the number of options that are coming up, I'd suggest you break the >> RFC down into two votes: A simple yes/no vote followed by an "if yes, how >> should it be implemented?" vote with the various options (the operators, >> functions, etc). If the RFC passes, then whichever option got a plurality >> of the votes would be the implemented option. >> > > This makes it more complicated because a language change requires 2/3 > majority while a new function requires 50% + 1. > > To make things simpler - and I believe it had been proposed before - the > main vote should include the implementation as a function and the secondary > vote should be for the operator. > > >> >> So yeah, I'd say bring it to a vote and that'll settle it one way or >> another. >> >> --Kris >> > > > > -- > -- > Tjerk > The problem is that, since that suggestion, other variations have been proposed with no clear favorite. How should we decide *which* proposed operator, for example? There have been several mentioned. --Kris