On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig <kris.cr...@gmail.com> wrote:
> > > > On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters <tjerk.meest...@gmail.com> > wrote: > >> >> >> >> On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig <kris.cr...@gmail.com> >> wrote: >> >>> On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds <a...@ajf.me> wrote: >>> >>> > >>> > On 17 Jul 2014, at 10:24, Nikita Popov <nikita....@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. > If the author can't settle on a particular operator, then a third vote would be necessary for those who vote to have an operator in the first place; perhaps a simple majority required for that. > > --Kris > > -- -- Tjerk
