Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE][RFC] Integer Semantics »

[VOTE][RFC] Integer Semantics

php.internals

Andrew Faulds

11 years ago
Good evening, This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21). https://wiki.php.net/rfc/integer_semantics#vote Thanks!
-- Andrea Faulds http://ajf.me/

Levi Morrison

11 years ago
> This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21). > > https://wiki.php.net/rfc/integer_semantics#vote
A few people have asked why I voted no; the only reason is that division by zero will return `false` and emit a warning. Integers can be converted to floating point numbers and dividing by zero in IEEE 754 is defined as INF. I would rather leave behavior undefined by voting no on this RFC than by defining it to a value which does not make sense to me. The value false will get converted to zero in any additional math, which is not the same as INF. The rest of the RFC looks very good, and would vote yes to it if division by zero was untouched or modified to use floating point division by zero.

Andrew Faulds

11 years ago
On 15 Sep 2014, at 17:24, Levi Morrison <levim@php.net> wrote:
>> This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21). >> >> https://wiki.php.net/rfc/integer_semantics#vote > > A few people have asked why I voted no; the only reason is that > division by zero will return `false` and emit a warning. Integers can > be converted to floating point numbers and dividing by zero in IEEE > 754 is defined as INF. I would rather leave behavior undefined by > voting no on this RFC than by defining it to a value which does not > make sense to me. The value false will get converted to zero in any > additional math, which is not the same as INF.
The RFC does not touch division by zero. That was a suggestion for a future RFC. I’ve now removed that section to avoid confusion.
-- Andrea Faulds http://ajf.me/

Dmitry Stogov

11 years ago
Hi Andrea, Shifts by negative number may make sense. (N << -1) => (N >> 1) At least receiving "false" from shift is not very pleasant. In the patch you use SIZEOF_LONG. It probably should be changed to SIZEOF_ZEND_LONG. Thanks. Dmitry. On Mon, Sep 15, 2014 at 8:31 PM, Andrea Faulds <ajf@ajf.me> wrote:

Andrew Faulds

11 years ago
On 16 Sep 2014, at 10:16, Dmitry Stogov <dmitry@zend.com> wrote:
> Shifts by negative number may make sense. (N << -1) => (N >> 1) > At least receiving "false" from shift is not very pleasant.
The problem is that changing from the current behaviour (undefined in C, but typically a shift by (PHP_INT_MAX - $bits)) to do what you’d expect (shift in the opposite direction) would be a silent BC break. I think it’s better to just stop it altogether and raise an E_WARNING, where it’s at least obvious something went wrong, than change this behaviour silently.
> In the patch you use SIZEOF_LONG. It probably should be changed to > SIZEOF_ZEND_LONG.
Will fix, thanks for spotting that.
-- Andrea Faulds http://ajf.me/

Dmitry Stogov

11 years ago
you already made silent break for N << 64 and N >> 64, but it may be explained as more consistent behaviour. I don't see a big difference with negative shifts. The real thing that I don't like - is a "boolean" result. Warning is not a big problem. Thanks. Dmitry. On Tue, Sep 16, 2014 at 1:23 PM, Andrea Faulds <ajf@ajf.me> wrote:

Chris Wright

11 years ago
On 16 September 2014 11:05, Dmitry Stogov <dmitry@zend.com> wrote:
> you already made silent break for N << 64 and N >> 64, but it may be > explained as more consistent behaviour. > I don't see a big difference with negative shifts. > > The real thing that I don't like - is a "boolean" result. Warning is not a > big problem.
I'm inclined to agree with this. The warning makes sense as it's almost certainly a userland bug, and if the expected old behaviour is desired it can easily be modified in userland, but returning FALSE doesn't make a huge amount of sense. This will almost certainly be immediately cast to int(0) by the next operation - almost no-one is going to actually check for a return value of FALSE - so it makes more sense to just return 0 and avoid the implicit cast. This would also produce possibly-unexpected results if a future operation was to stringify the result, as FALSE would cast to the empty string. I have voted in favour of the RFC as it stands as I believe that overall the changes are positive, but ideally this particular case would be addressed.

Andrew Faulds

11 years ago
On 16 Sep 2014, at 11:19, Chris Wright <cw@daverandom.com> wrote:
> On 16 September 2014 11:05, Dmitry Stogov <dmitry@zend.com> wrote: >> you already made silent break for N << 64 and N >> 64, but it may be >> explained as more consistent behaviour. >> I don't see a big difference with negative shifts. >> >> The real thing that I don't like - is a "boolean" result. Warning is not a >> big problem. > > I'm inclined to agree with this. The warning makes sense as it's > almost certainly a userland bug, and if the expected old behaviour is > desired it can easily be modified in userland, but returning FALSE > doesn't make a huge amount of sense. This will almost certainly be > immediately cast to int(0) by the next operation - almost no-one is > going to actually check for a return value of FALSE - so it makes more > sense to just return 0 and avoid the implicit cast. This would also > produce possibly-unexpected results if a future operation was to > stringify the result, as FALSE would cast to the empty string. > > I have voted in favour of the RFC as it stands as I believe that > overall the changes are positive, but ideally this particular case > would be addressed.
The choice of bool(false) was due to precedent. This is what we do for a division by zero. I agree that some other value would make more sense, but I couldn’t think of a better one, so I just stuck with the existing behaviour for div0.
-- Andrea Faulds http://ajf.me/

Pascal MARTIN

11 years ago
On 15/09/2014 00:23, Andrea Faulds wrote:
> This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21). > > https://wiki.php.net/rfc/integer_semantics#vote
Hi, After discussing this RFC with other members of AFUP (French UG), we agree that improving cross-platform consistency is important, so +1. Users of a high-level language such as PHP should not, in our opinion, have to worry about the kind of differences this RFC wants to fix. Of course, changing this now might break some scripts here and there, but probably not that many of them (as it's about edge-cases for bitwise shifts, which were already giving different results depending on the platform, and odd casts) -- and PHP 7 (major version) feels like the right time to fix this.
-- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin

Juan Basso

11 years ago
Why don't you throw an exception instead of returning random things that are not accurate? It makes the response of the operation or casts more realistic, since you will never get INF or NAN as result and possibly transform it to 0 unconsciously. It will keep the semantic for expected types, for example, a division of 2 integers can result in a integer or float, but never boolean. Exceptions are there since PHP 5 and it is largely used by frameworks and developers. It is not a new or not used concept. I guess using them bring more value to the language than keeping the "lets define a default value for this case and worry about the other cases later". It just adds more confusion to developers to know if certain things returns 0, false, -1, etc for all different functions/operations across the language. Juan Basso

Andrew Faulds

11 years ago
On 14 Sep 2014, at 23:23, Andrea Faulds <ajf@ajf.me> wrote:
> Good evening, > > This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21). > > https://wiki.php.net/rfc/integer_semantics#vote > > Thanks!
The vote has now closed. The result was 16:8 Yes:No, which meets the 2/3 majority and therefore the RFC is accepted. I’ll merge the patch soon. I understand some people objected to (int)INF and (int)NAN resulting in zero. For that reason, I’m going to consider writing an RFC to make them error instead sometime soon. Thanks!
-- Andrea Faulds http://ajf.me/

Laruence

11 years ago
Hey: On Sun, Sep 21, 2014 at 7:17 AM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 14 Sep 2014, at 23:23, Andrea Faulds <ajf@ajf.me> wrote: > >> Good evening, >> >> This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21). >> >> https://wiki.php.net/rfc/integer_semantics#vote >> >> Thanks! > > The vote has now closed. The result was 16:8 Yes:No, which meets the 2/3 majority and therefore the RFC is accepted. I’ll merge the patch soon.
it should be closed tomorrow, not today.
> > I understand some people objected to (int)INF and (int)NAN resulting in zero. For that reason, I’m going to consider writing an RFC to make them error instead sometime soon. > > Thanks! > > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- Xinchen Hui @Laruence http://www.laruence.com/

Andrew Faulds

11 years ago
> On 21 Sep 2014, at 03:52, Xinchen Hui <laruence@php.net> wrote: > > Hey: > > it should be closed tomorrow, not today.
It's the 21st in my timezone. I started the vote at 2am on the 14th and it's now 4am on the 21st. I don't see a problem.
-- Andrea Faulds http://ajf.me/

Laruence

11 years ago
On Sun, Sep 21, 2014 at 11:03 AM, Andrea Faulds <ajf@ajf.me> wrote:
> >> On 21 Sep 2014, at 03:52, Xinchen Hui <laruence@php.net> wrote: >> >> Hey: >> >> it should be closed tomorrow, not today. > > It's the 21st in my timezone. I started the vote at 2am on the 14th and it's now 4am on the 21st. I don't see a problem.
the problem is, you only get 16:8 on today. and it's weekend. that means your RFC is not very common acceptable. (I have strong objection on it). and it's weekend, so, it's better to wait one day more.. anyway, I see you already commit your patch... which is not very good. thanks
> -- > Andrea Faulds > http://ajf.me/
-- Xinchen Hui @Laruence http://www.laruence.com/

Pierre Joye

11 years ago
Hi, On Sep 21, 2014 10:08 AM, "Xinchen Hui" <laruence@php.net> wrote:
> > On Sun, Sep 21, 2014 at 11:03 AM, Andrea Faulds <ajf@ajf.me> wrote: > > > >> On 21 Sep 2014, at 03:52, Xinchen Hui <laruence@php.net> wrote: > >> > >> Hey: > >> > >> it should be closed tomorrow, not today. > > > > It's the 21st in my timezone. I started the vote at 2am on the 14th and
it's now 4am on the 21st. I don't see a problem.
> > the problem is, you only get 16:8 on today. and it's weekend. > > that means your RFC is not very common acceptable. (I have strong > objection on it). > > and it's weekend, so, it's better to wait one day more.. > > anyway, I see you already commit your patch... which is not very good. >
I did not manage to vote while being on the road. But I am +1. So consider it as, theoretically, 17:8. However the nitpicking about votes periods, % and co is getting annoying. I will see if we can clarify that. To use all possible ways to block or push RFCs is getting counter productive and produce a bad experience. Cheers, Pierre

Laruence

11 years ago
On Sun, Sep 21, 2014 at 11:33 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> Hi, > On Sep 21, 2014 10:08 AM, "Xinchen Hui" <laruence@php.net> wrote: >> >> On Sun, Sep 21, 2014 at 11:03 AM, Andrea Faulds <ajf@ajf.me> wrote: >> > >> >> On 21 Sep 2014, at 03:52, Xinchen Hui <laruence@php.net> wrote: >> >> >> >> Hey: >> >> >> >> it should be closed tomorrow, not today. >> > >> > It's the 21st in my timezone. I started the vote at 2am on the 14th and >> > it's now 4am on the 21st. I don't see a problem. >> >> the problem is, you only get 16:8 on today. and it's weekend. >> >> that means your RFC is not very common acceptable. (I have strong >> objection on it). >> >> and it's weekend, so, it's better to wait one day more.. >> >> anyway, I see you already commit your patch... which is not very good. >> > > I did not manage to vote while being on the road. But I am +1. So consider > it as, theoretically, 17:8.
why you didn't? there are lot's of people didn't vote. so how to count theirs vote? (please if you have opinion.. then vote)
> > However the nitpicking about votes periods, % and co is getting annoying. I > will see if we can clarify that. To use all possible ways to block or push > RFCs is getting counter productive and produce a bad experience.
and nervemind. I respect the RFC process, even I don't like this RFC thanks
> > Cheers, > Pierre
-- Xinchen Hui @Laruence http://www.laruence.com/

Pierre Joye

11 years ago
On Sep 21, 2014 10:48 AM, "Xinchen Hui" <laruence@php.net> wrote:
> > On Sun, Sep 21, 2014 at 11:33 AM, Pierre Joye <pierre.php@gmail.com>
wrote:
> > Hi, > > On Sep 21, 2014 10:08 AM, "Xinchen Hui" <laruence@php.net> wrote: > >> > >> On Sun, Sep 21, 2014 at 11:03 AM, Andrea Faulds <ajf@ajf.me> wrote: > >> > > >> >> On 21 Sep 2014, at 03:52, Xinchen Hui <laruence@php.net> wrote: > >> >> > >> >> Hey: > >> >> > >> >> it should be closed tomorrow, not today. > >> > > >> > It's the 21st in my timezone. I started the vote at 2am on the 14th
and
> >> > it's now 4am on the 21st. I don't see a problem. > >> > >> the problem is, you only get 16:8 on today. and it's weekend. > >> > >> that means your RFC is not very common acceptable. (I have strong > >> objection on it). > >> > >> and it's weekend, so, it's better to wait one day more.. > >> > >> anyway, I see you already commit your patch... which is not very good. > >> > > > > I did not manage to vote while being on the road. But I am +1. So
consider
> > it as, theoretically, 17:8. > why you didn't? > > there are lot's of people didn't vote. so how to count theirs vote? > > (please if you have opinion.. then vote)
It is closed now.
> > > > However the nitpicking about votes periods, % and co is getting
annoying. I
> > will see if we can clarify that. To use all possible ways to block or
push
> > RFCs is getting counter productive and produce a bad experience. > > and nervemind. I respect the RFC process, even I don't like this RFC
:-)

Peter Cowburn

11 years ago
On 21 September 2014 04:53, Pierre Joye <pierre.php@gmail.com> wrote:
> On Sep 21, 2014 10:48 AM, "Xinchen Hui" <laruence@php.net> wrote: > > > > On Sun, Sep 21, 2014 at 11:33 AM, Pierre Joye <pierre.php@gmail.com> > wrote: > > > Hi, > > > On Sep 21, 2014 10:08 AM, "Xinchen Hui" <laruence@php.net> wrote: > > >> > > >> On Sun, Sep 21, 2014 at 11:03 AM, Andrea Faulds <ajf@ajf.me> wrote: > > >> > > > >> >> On 21 Sep 2014, at 03:52, Xinchen Hui <laruence@php.net> wrote: > > >> >> > > >> >> Hey: > > >> >> > > >> >> it should be closed tomorrow, not today. > > >> > > > >> > It's the 21st in my timezone. I started the vote at 2am on the 14th > and > > >> > it's now 4am on the 21st. I don't see a problem. > > >> > > >> the problem is, you only get 16:8 on today. and it's weekend. > > >> > > >> that means your RFC is not very common acceptable. (I have strong > > >> objection on it). > > >> > > >> and it's weekend, so, it's better to wait one day more.. > > >> > > >> anyway, I see you already commit your patch... which is not very good. > > >> > > > > > > I did not manage to vote while being on the road. But I am +1. So > consider > > > it as, theoretically, 17:8. > > why you didn't? > > > > there are lot's of people didn't vote. so how to count theirs vote? > > > > (please if you have opinion.. then vote) > > It is closed now. >
The vote is closed now, fact. That does not prevent further (hopefully productive) discussion from happening, and it also doesn’t stipulate that the RFC must be merged. Closing the vote at the most convenient opportunity, when it suits the author most, is not cool. Andrea has been pushing for a while to scrape enough votes together to get this through, as a “prerequisite" for the bigint RFC–which apparently would include these changes anyway, regardless of the outcome of this vote– even asking “no” voters on multiple occasions to rescind their votes. So. Not. Cool.

Andrew Faulds

11 years ago
On 21 Sep 2014, at 22:49, Peter Cowburn <petercowburn@gmail.com> wrote:
> It is closed now. > > The vote is closed now, fact. That does not prevent further (hopefully productive) discussion from happening, and it also doesn’t stipulate that the RFC must be merged.
The RFC is merged. I suppose you could revert the changes, though it’d be a significant hassle.
> Closing the vote at the most convenient opportunity, when it suits the author most, is not cool.
I didn’t close it because the time suited me most. I made an honest mistake and closed it 22 or so hours early because I forgot I’d opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised my mistake after merging the patch. This was definitely not intentional.
-- Andrea Faulds http://ajf.me/