# [VOTE][RFC] Integer Semantics - Thread: https://externals.io/message/77201 - Original archive: https://news-web.php.net/php.internals/77201 - Started by Andrea Faulds on 2014-09-14T22:23:54+00:00 - Messages: 40 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/77201.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #77201 — Andrea Faulds — 2014-09-14T22:23:54+00:00 URL: https://externals.io/message/77201#77201 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/ --- ## #77222 — Levi Morrison — 2014-09-15T16:24:01+00:00 URL: https://externals.io/message/77201#77222 · In reply to: #77201 > 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. --- ## #77223 — Andrea Faulds — 2014-09-15T16:31:57+00:00 URL: https://externals.io/message/77201#77223 · In reply to: #77222 > > […] > > 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/ --- ## #77238 — Dmitry Stogov — 2014-09-16T09:16:18+00:00 URL: https://externals.io/message/77201#77238 · In reply to: #77223 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. > > > > > […] > in a week’s time (2014-09-21). > > […] > > 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/ --- ## #77239 — Andrea Faulds — 2014-09-16T09:23:46+00:00 URL: https://externals.io/message/77201#77239 · In reply to: #77238 > 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/ --- ## #77241 — Dmitry Stogov — 2014-09-16T10:05:43+00:00 URL: https://externals.io/message/77201#77241 · In reply to: #77239 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. > > > > > […] > > 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. > > > […] > > Will fix, thanks for spotting that. > > -- > Andrea Faulds > http://ajf.me/ --- ## #77242 — Chris Wright — 2014-09-16T10:19:25+00:00 URL: https://externals.io/message/77201#77242 · In reply to: #77241 > 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. > > Thanks. Dmitry. > > > > > > > […] --- ## #77244 — Andrea Faulds — 2014-09-16T12:36:37+00:00 URL: https://externals.io/message/77201#77244 · In reply to: #77242 > > > […] > > 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/ --- ## #77392 — Juan Basso — 2014-09-20T19:42:56+00:00 URL: https://externals.io/message/77201#77392 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 --- ## #77395 — Andrea Faulds — 2014-09-20T23:17:47+00:00 URL: https://externals.io/message/77201#77395 · In reply to: #77201 > 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/ --- ## #77402 — Xinchen Hui — 2014-09-21T02:52:22+00:00 URL: https://externals.io/message/77201#77402 · In reply to: #77395 Hey: > > > > > […] > > 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/ > > > > > > -- > > > -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #77403 — Andrea Faulds — 2014-09-21T03:03:45+00:00 URL: https://externals.io/message/77201#77403 · In reply to: #77402 > > > 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/ --- ## #77404 — Xinchen Hui — 2014-09-21T03:07:33+00:00 URL: https://externals.io/message/77201#77404 · In reply to: #77403 > > > […] > > 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/ --- ## #77405 — Pierre Joye — 2014-09-21T03:33:24+00:00 URL: https://externals.io/message/77201#77405 · In reply to: #77404 Hi, > > > > […] 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 --- ## #77406 — Xinchen Hui — 2014-09-21T03:48:34+00:00 URL: https://externals.io/message/77201#77406 · In reply to: #77405 > Hi, > > > […] > > 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/ --- ## #77407 — Pierre Joye — 2014-09-21T03:53:44+00:00 URL: https://externals.io/message/77201#77407 · In reply to: #77406 > > On Sun, Sep 21, 2014 at 11:33 AM, Pierre Joye wrote: > > […] and > > […] consider > > […] > 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. > > […] annoying. I > > […] push > > […] > > and nervemind. I respect the RFC process, even I don't like this RFC :-) > thanks > > […] > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ --- ## #77419 — Peter Cowburn — 2014-09-21T21:49:45+00:00 URL: https://externals.io/message/77201#77419 · In reply to: #77407 > > > […] > wrote: > > […] > and > > […] > consider > > […] > > 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. > > > […] > annoying. I > > […] > push > > […] > > :-) > > > […] --- ## #77421 — Andrea Faulds — 2014-09-21T23:05:17+00:00 URL: https://externals.io/message/77201#77421 · In reply to: #77419 > 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/ --- ## #77437 — Peter Cowburn — 2014-09-22T09:02:45+00:00 URL: https://externals.io/message/77201#77437 · In reply to: #77421 > > On 21 Sep 2014, at 22:49, Peter Cowburn > wrote: > > > […] > 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. Immediately reverting a change is a knee-jerk reaction that should not take place. That said, this vote was closed early, whether deliberately or not, and merged, which goes against everything we've been aiming for with the RFC process. > > > […] > 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. If you say so. Still, the asking of individuals to remove their votes so that the tally is in you favour is inexcusable. > -- > Andrea Faulds > http://ajf.me/ --- ## #77440 — Pierre Joye — 2014-09-22T09:21:29+00:00 URL: https://externals.io/message/77201#77440 · In reply to: #77437 > > If you say so. Still, the asking of individuals to remove their votes so > that the tally is in you favour is inexcusable. did I miss something? What is this "request to remove votes" thing? -- Pierre @pierrejoye | http://www.libgd.org --- ## #77442 — Peter Cowburn — 2014-09-22T09:35:51+00:00 URL: https://externals.io/message/77201#77442 · In reply to: #77440 > On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn > wrote: > > > […] > > did I miss something? What is this "request to remove votes" thing? > Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5] In summary, Andrea asked individuals, myself included, several times to remove their “no” votes purely to cross the 2/3 majority threshold. That, along with their timely concerns raised both on- and off-list about who can vote, leads me to think… “shenanigans”. [6] What’s done is done, the RFC passed and was merged… let’s move along to getting stuff done. > > > -- > Pierre > > @pierrejoye | http://www.libgd.org > [1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597 [2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500 [3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456 [4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542 [5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711 [6] http://dictionary.reference.com/browse/shenanigans --- ## #77443 — Michael Wallner — 2014-09-22T09:36:45+00:00 URL: https://externals.io/message/77201#77443 · In reply to: #77440 WTF is going on here? Looks like the vote was closed nearly 24 hours early on a weekend. While the latter is not nice, closing early is a no-go. So what are we going to do? Reopen the vote for another day or completely restart it? -- Regards, Mike --- ## #77444 — Pierre Joye — 2014-09-22T09:42:20+00:00 URL: https://externals.io/message/77201#77444 · In reply to: #77443 > > WTF is going on here? Looks like the vote was closed nearly 24 hours > early on a weekend. While the latter is not nice, closing early is a > no-go. So what are we going to do? Reopen the vote for another day or > completely restart it? This is getting really annoying. 2nd or 3rd time it happens, between people changing contents during votes, closing too early, too late, asking to change votes, etc. As we can't fix the lobbying part of it we can fix the time, content and periods issue. I will drop a mail later today to propose a solution, avoiding this. -- Pierre @pierrejoye | http://www.libgd.org --- ## #77445 — Xinchen Hui — 2014-09-22T09:46:34+00:00 URL: https://externals.io/message/77201#77445 · In reply to: #77442 > > > > > […] > > > Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5] > > In summary, Andrea asked individuals, myself included, several times to > remove their “no” votes purely to cross the 2/3 majority threshold. That, > along with their timely concerns raised both on- and off-list about who can > vote, leads me to think… “shenanigans”. [6] ask people to vote yes, close the vote immeditely once it reach the 2/3 requirement.. it's not cool, and it's not about RFC process... it's about manner... thanks > > What’s done is done, the RFC passed and was merged… let’s move along to > getting stuff done. > > > […] > > > [1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597 > [2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500 > [3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456 > [4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542 > [5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711 > [6] http://dictionary.reference.com/browse/shenanigans -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #77446 — Andrea Faulds — 2014-09-22T09:48:52+00:00 URL: https://externals.io/message/77201#77446 · In reply to: #77445 > ask people to vote yes, close the vote immeditely once it reach the > 2/3 requirement.. > > it's not cool, and it's not about RFC process... it's about manner… I didn’t close it because it reached the 2/3 requirement. I was lucky that one more person voted before I closed it. I made an honest mistake and closed it too early. -- Andrea Faulds http://ajf.me/ --- Next page: https://externals.io/message/77201.md?page=2