# [VOTE][RFC] Coercive Scalar Type Hints - Thread: https://externals.io/message/84548 - Original archive: https://news-web.php.net/php.internals/84548 - Started by Zeev Suraski on 2015-03-11T15:10:44+00:00 - Messages: 31 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/84548.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 --- ## #84548 — Zeev Suraski — 2015-03-11T15:10:44+00:00 URL: https://externals.io/message/84548#84548 The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string->bool and int->bool conversions (false->bool is not supported) 2. Accept leading/trailing spaces in string->number conversions. wiki.php.net/rfc/coercive_sth wiki.php.net/rfc/coercive_sth#vote Thanks! Zeev --- ## #84549 — Anthony Ferrara — 2015-03-11T15:19:31+00:00 URL: https://externals.io/message/84548#84549 · In reply to: #84548 Zeev, Considering that there has not been any discussion of your final proposal (since the last change), I think putting it to vote prior to having the ability to test or discuss is extremely problematic. Especially considering every time we tried to test the proposal or discuss it before you said that you needed to "tweak the rules". Now opening vote without giving the ability for people to test it or discuss prior to voting is extremely bad form. I **strongly** suggest that you retract the vote and open discussion on the final proposal. Anthony > The vote on the Coercive Scalar Type Hints is now open for voting. > > > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) > > 2. Accept leading/trailing spaces in string->number conversions. > > > > wiki.php.net/rfc/coercive_sth > > wiki.php.net/rfc/coercive_sth#vote > > > > Thanks! > > > > Zeev --- ## #84550 — Zeev Suraski — 2015-03-11T15:49:59+00:00 URL: https://externals.io/message/84548#84550 · In reply to: #84549 Anthony, While I only put in the final changes today, they're identical to what I said was going to be done on the discussion thread a week+ ago, there was no further feedback or discussion on these changes. The patch (minus these two minor changes) has been available for over a week. I think we've had enough drama with scalar type hints already and it's time for closure. Let's let the two votes go through and finally get clarity. If people find big rejects on the tweaked patch which requires substantial meaningful changes - I'll restart the vote if necessary. Thanks, Zeev > -----Original Message----- > From: Anthony Ferrara [mailto:ircmaxell@gmail.com] > Sent: Wednesday, March 11, 2015 5:20 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > Zeev, > > Considering that there has not been any discussion of your final proposal > (since the last change), I think putting it to vote prior to having the > ability to > test or discuss is extremely problematic. > Especially considering every time we tried to test the proposal or discuss > it > before you said that you needed to "tweak the rules". Now opening vote > without giving the ability for people to test it or discuss prior to > voting is > extremely bad form. > > I **strongly** suggest that you retract the vote and open discussion on > the > final proposal. > > Anthony > > > > […] --- ## #84551 — Dan Ackroyd — 2015-03-11T15:52:55+00:00 URL: https://externals.io/message/84548#84551 · In reply to: #84548 Voting no due to: i) Having conversion rules be difference in userland to internal functions. You list 'Single Mode' as a benefit of this RFC, but it's only single mode if you gloss over this difference. This is a massive cognitive load, and will be one of those issues that catches users out again and again. Why on earth should a boolean be convertible to int for some functions but not others? What will happen when someone writes code that extends an internal class and overrides one of the functions, is that the person who is using that extended class will have to alter their code to use the extended class in a different way to how they would use the built in class directly. For everyone who didn't pick this up in the RFC, it's hidden in the large chunk of text: "Unlike user-land scalar type hints, internal functions will accept nulls as valid scalars." ii) The subtle BC breaks. false -> int # No more conversion from bool true -> string # No more conversion from bool btw You appear to have only tested this code against barebones frameworks. These are often written far more cleanly than actual applications so I don't think the report of 'very limited' BC breaks is accurate. iii) Having conversion work, except when they don't. People who want weak type hints want weak type hints - they don't want code that breaks unexpectedly. function foo(int $bar){...} foo(36/$value); // works when $value = 1, 2, 3, 4 breaks when $value = 5 This is neither weak nor strict type - this is a horrible hybrid that would only catch people out. But finally, the fact that a significant part of the RFC is talking about how the behaviour will need to be cleaned up in a future RFC, but at the same time that some of the problems will be left for five years show that this isn't a sensible RFC to vote for, even for the people who just want weak types cheers Dan . > The vote on the Coercive Scalar Type Hints is now open for voting. > > > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) > > 2. Accept leading/trailing spaces in string->number conversions. > > > > wiki.php.net/rfc/coercive_sth > > wiki.php.net/rfc/coercive_sth#vote > > > > Thanks! > > > > Zeev --- ## #84552 — Derick Rethans — 2015-03-11T15:56:48+00:00 URL: https://externals.io/message/84548#84552 · In reply to: #84548 > The vote on the Coercive Scalar Type Hints is now open for voting. > > > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) > > 2. Accept leading/trailing spaces in string->number conversions. Aren't you supposed to leave it one week between annoucing the latest RFC with your changes, and the real vote? Actually, now I read it, it should actually be two weeks ... but then I guess it was just a tweak on an earlier version: https://wiki.php.net/rfc/voting#discussion_period cheers, Derick --- ## #84553 — Florian Margaine — 2015-03-11T16:11:46+00:00 URL: https://externals.io/message/84548#84553 · In reply to: #84552 Hi, Derick Rethans writes: > > > > […] > > Aren't you supposed to leave it one week between annoucing the latest > RFC with your changes, and the real vote? I'm reading that the delay is one week after announcing the intent to vote. Which means that the RFC is in final state before voting, and the author has announced intention to vote. I haven't seen the mail announcing this, did I miss it? There were a lot of mails on internals lately, it may be possible. If this mail wasn't sent, should the rules be different because there was a lot of debate on this RFC? Then which other rule should be broken? > > Actually, now I read it, it should actually be two weeks ... but then I > guess it was just a tweak on an earlier version: > https://wiki.php.net/rfc/voting#discussion_period I guess that since there was a lot of discussion, shortening to one week makes sense. > > cheers, > Derick Cheers, -- Florian Margaine --- ## #84555 — Zeev Suraski — 2015-03-11T16:31:52+00:00 URL: https://externals.io/message/84548#84555 · In reply to: #84552 > -----Original Message----- > From: Derick Rethans [mailto:derick@php.net] > Sent: Wednesday, March 11, 2015 5:57 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > > Aren't you supposed to leave it one week between annoucing the latest RFC > with your changes, and the real vote? > > Actually, now I read it, it should actually be two weeks ... but then I guess it > was just a tweak on an earlier version: > https://wiki.php.net/rfc/voting#discussion_period That period is between the RFC is "brought up on the list" and when the voting starts. It doesn't say anywhere that there's a mandatory discussion period after the last change on the RFC. The mandatory two week discussion period includes changes to the RFC as a part of the discussion cycle and doesn't reset on every change. It was announced on internals almost 3 weeks ago, by one of the authors, as a concrete RFC to be voted on for PHP 7.0. Zeev --- ## #84556 — Anthony Ferrara — 2015-03-11T16:42:38+00:00 URL: https://externals.io/message/84548#84556 · In reply to: #84551 All, > Voting no due to: > > i) Having conversion rules be difference in userland to internal functions. > > You list 'Single Mode' as a benefit of this RFC, but it's only single > mode if you gloss over this difference. This is a massive cognitive > load, and will be one of those issues that catches users out again and > again. Why on earth should a boolean be convertible to int for some > functions but not others? > > What will happen when someone writes code that extends an internal > class and overrides one of the functions, is that the person who is > using that extended class will have to alter their code to use the > extended class in a different way to how they would use the built in > class directly. > > For everyone who didn't pick this up in the RFC, it's hidden in the > large chunk of text: > "Unlike user-land scalar type hints, internal functions will accept > nulls as valid scalars." > > > ii) The subtle BC breaks. > > false -> int # No more conversion from bool > true -> string # No more conversion from bool > > btw You appear to have only tested this code against barebones > frameworks. These are often written far more cleanly than actual > applications so I don't think the report of 'very limited' BC breaks > is accurate. > > > iii) Having conversion work, except when they don't. People who want > weak type hints want weak type hints - they don't want code that > breaks unexpectedly. > > function foo(int $bar){...} > > foo(36/$value); > // works when $value = 1, 2, 3, 4 breaks when $value = 5 > > This is neither weak nor strict type - this is a horrible hybrid that > would only catch people out. > > But finally, the fact that a significant part of the RFC is talking > about how the behaviour will need to be cleaned up in a future RFC, > but at the same time that some of the problems will be left for five > years show that this isn't a sensible RFC to vote for, even for the > people who just want weak types > > cheers > Dan > In addition, I'm voting no for the following reasons (in addition to Dan's): 1. It downplays the BC breaks. It says: > Given the change to the acceptable values into a wide range of internal functions, this RFC is likely to result in a substantial number of newly introduced `E_DEPRECATED` warnings in internal function invocations, although those can be easily suppressed So BC breaks are fine, as long as they are *easily suppressed*. This is madness, as they won't be able to be suppressed in 8 (when they will be turned into hard breaks). 2. It judges the BC breaks based on skeleton applications (Drupal 7's stock home page, Drupal 7's stock admin interface, Magento's home page, Wordpress's home page, ZF2's skeleton app, Symfony's ACME app). It doesn't bring up unit tests (which Symfony was shown to have many failures). It doesn't show running on non-framework code. It doesn't show the average Wordpress/Drupal module for example. 3. It contains massive misinformation. > It is our position that there is no difference at all between strict and coercive typing in terms of potential future AOT/JIT development - none at all. And > It is the position of several Strict STH proponents that Strict STH can help static analysis in certain cases. For the same reasons mentioned above about JIT, we don't believe that is the case - although it's possible that Strict Typing may be able to help static analysis in certain edge cases. However, it is our belief that even if that is true, Static Analyzers need to be designed for Languages, rather than Languages being designed for Static Analyzers. Yet the JavaScript community is discovering the exact opposite, and is looking into a extremely similar dual-mode: https://developers.google.com/v8/experiments 4. It makes claims against the [dual mode RFC](https://wiki.php.net/rfc/scalar_type_hints_v5) that apply to this RFC. For example: > Too strict may lead to too lax. In the Dual Mode RFC, when in Strict mode, in many cases, functions would reject values that, semantically, are acceptable. For example, a “32” (string) value coming back from an integer column in a database table, would not be accepted as valid input for a function expecting an integer. Since semantically the developer is interested in this argument-passing succeeding, they would have the choice of either removing the integer STH altogether, or, more likely, explicitly casting the value into an integer. This would have the opposite of the desired outcome of strict STHs - as explicit casts ($foo = (int) $foo;) always succeed, and would happily convert “100 dogs”, “Apples” and even arrays and booleans into an integer. Further, since already today, internal functions employ coercion rules that are more restrictive than PHP's explicit casting, pushing people towards explicit casting will actually make things worse in case developers opt for explicit casting as they pass values in an internal function call. Yet it completely ignores the fact that the identical situation appears with the coercive mode RFC. The difference is that with Dual-Mode, it's 100% opt-in, where with coercive you're forced to add casts. 5. It's full of logical inconsistencies: For example, given the following code: function foo(bool $abc) {} These calls work: foo(true); foo(1); foo("test"); While these fail (note they don't fail on 5.x): foo(1.0); foo(array()); foo(null); Why is `int` accepted for `bool`, but `float` rejected??? And that's not even mentioning that this has been put to vote without having the final version put up for discussion. There were [12 non-voting related changes in the past 28 hours](https://wiki.php.net/rfc/coercive_sth?do=revisions). Some of them are likely trivial tweaks, but some like `allow int/string -> bool conversion` are definitely not trivial. I can't actually pull a diff of the changes due to errors on wiki.php.net, so I can't tell exactly what was changed... I'll open another thread about last-minute changes prior to opening vote, because that has to stop. Anthony --- ## #84557 — Zeev Suraski — 2015-03-11T16:45:32+00:00 URL: https://externals.io/message/84548#84557 · In reply to: #84551 > -----Original Message----- > From: Dan Ackroyd [mailto:danack@basereality.com] > Sent: Wednesday, March 11, 2015 5:53 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > Voting no due to: > > i) Having conversion rules be difference in userland to internal > functions. > > You list 'Single Mode' as a benefit of this RFC, but it's only single mode > if you > gloss over this difference. This is a massive cognitive load, and will be > one of > those issues that catches users out again and again. Why on earth should a > boolean be convertible to int for some functions but not others? Bool->int is not allowed across the board. Yes, in 7 internal functions will emit `E_DEPRECATED` and userland will reject, but that's a transition period but the rules are the same for both. > What will happen when someone writes code that extends an internal class > and overrides one of the functions, is that the person who is using that > extended class will have to alter their code to use the extended class in > a > different way to how they would use the built in class directly. > > For everyone who didn't pick this up in the RFC, it's hidden in the large > chunk > of text: > "Unlike user-land scalar type hints, internal functions will accept nulls > as valid > scalars." NULLs are a different case, that's true, but it actually can be resolved in the future (as is mentioned in the RFC). The key problem with rejecting NULLs for internal functions in the same way they are for userland is that this is the standard way you can denote an 'empty' argument. E.g., mysqli_connect(null, $username, $password). The problem is that function implementations rely on coercion of null->string and treat empty strings as if no argument was supplied. We can easily change it so that these function explicitly accept NULLs (which is already a supported modifier for ZPP), and then have explicit handling for `NULL` as a non-argument. Since it requires many changes in extension code - that's something that's probably too big for us to pull off for 7.0, but we can most probably do it for 7.1. Also, if we accept nullable type hints (https://wiki.php.net/rfc/nullable_types_rfc) the discrepancy will practically disappear, as you'd be able to denote an int/null hint in the very same way you can do it for internal functions. > ii) The subtle BC breaks. > > false -> int # No more conversion from bool > true -> string # No more conversion from bool That's fair; I think the breakage is very limited and worth the gains, but that's obviously subjective. Clearly, going for a single mode and making it stricter than what we have today does mean some level of compatibility breakage by definition - each person should form their opinion on whether that's worth it or not. > > btw You appear to have only tested this code against barebones > frameworks. These are often written far more cleanly than actual > applications so I don't think the report of 'very limited' BC breaks is > accurate. I don't view Magento, Drupal and Wordpress aren't barebones frameworks. They're pretty full featured real world apps (that also happen to be frameworks). > iii) Having conversion work, except when they don't. People who want weak > type hints want weak type hints - they don't want code that breaks > unexpectedly. > > function foo(int $bar){...} > > foo(36/$value); > // works when $value = 1, 2, 3, 4 breaks when $value = 5 > > This is neither weak nor strict type - this is a horrible hybrid that > would only > catch people out. Ultimately it's all about a signal to noise ratio. I think that strict STH has horrible signal to noise ratio; Weak type hints can easily allow problematic values to be glossed over and accepted - so there's zero noise, but also zero signal in case of trouble. This RFC proposes a rule-set that has very good signal to noise ratio, but of course, there are edge cases here and there. Personally, I don't feel that all the x div y examples that were/are commonly brought up in the context of float/int conversions are very real world, but rather, such edge cases - but here too, each person can form their opinion about it... It seems a key thing you don't like about the RFC is that it's transitional (what you call 'cleanup'). That's fair, but personally, I think that going through a transition period that on one hand allows both our codebase and more importantly our users' codebase to evolve - and that ultimately results in one, consistent language behavior is better than the alternatives (two modes that will never ever converge). Either way, thanks for the feedback! Zeev --- ## #84561 — Zeev Suraski — 2015-03-11T17:15:45+00:00 URL: https://externals.io/message/84548#84561 · In reply to: #84556 > In addition, I'm voting no for the following reasons (in addition to > Dan's): > > 1. It downplays the BC breaks. It says: > > > […] > internal > functions, this RFC is likely to result in a substantial number of newly > introduced `E_DEPRECATED` warnings in internal function invocations, > although those can be easily suppressed > > So BC breaks are fine, as long as they are *easily suppressed*. > This is madness, as they won't be able to be suppressed in 8 (when they > will > be turned into hard breaks). If you copied the whole paragraph (one more sentence) instead of it out of context it would be clear that we're not at all downplaying anything. We're portraying it exactly for what it is, for better or worse. The fact users would have years to adjust is radically different from if we broke compatibility overnight, and that's exactly what this paragraph conveys. > 2. It judges the BC breaks based on skeleton applications (Drupal 7's > stock > home page, Drupal 7's stock admin interface, Magento's home page, > Wordpress's home page, ZF2's skeleton app, Symfony's ACME app). > It doesn't bring up unit tests (which Symfony was shown to have many > failures). It doesn't show running on non-framework code. It doesn't show > the average Wordpress/Drupal module for example. I don't consider Drupal/Magento or WordPress framework code. It's real world apps, very very similar to other custom-coded real world apps. > 3. It contains massive misinformation. > > > […] > strict and > coercive typing in terms of potential future AOT/JIT development - none at > all. It's our position, the position of people very well versed in this area that have written a JIT compiler that runs blazingly fast with no type hints at all. It's fine that you have a different opinion. One of us is wrong. > Yet the JavaScript community is discovering the exact opposite, and is > looking into a extremely similar dual-mode: > https://developers.google.com/v8/experiments This is hardly the exact opposite. It means something we agreed on from the get go - if you *change* your code so that the compiler can gain more insight on what the types are during compile-time (e.g. an explicit cast, or if we add typed variable declarations) - then sure, there'll be AOT/JIT gains - but they're absolutely not coming from the difference in type hints. I still contend that with coercive type hints we can perform the exact same static analysis, with just differently phrased output such as "it may need to be converted" rather than "will be rejected". Identical type inference rules. Identical everything, just slightly modified text. > 4. It makes claims against the [dual mode > RFC](https://wiki.php.net/rfc/scalar_type_hints_v5) that apply to this > RFC. > For example: > > > […] > mode, in many cases, functions would reject values that, semantically, are > acceptable. For example, a “32” (string) value coming back from an integer > column in a database table, would not be accepted as valid input for a > function expecting an integer. Since semantically the developer is > interested > in this argument-passing succeeding, they would have the choice of either > removing the integer STH altogether, or, more likely, explicitly casting > the > value into an integer. This would have the opposite of the desired outcome > of strict STHs - as explicit casts ($foo = (int) $foo;) always succeed, > and > would happily convert “100 dogs”, “Apples” and even arrays and booleans > into an integer. Further, since already today, internal functions employ > coercion rules that are more restrictive than PHP's explicit casting, > pushing > people towards explicit casting will actually make things worse in case > developers opt for explicit casting as they pass values in an internal > function > call. > > Yet it completely ignores the fact that the identical situation > appears with > the coercive mode RFC. The difference is that with Dual-Mode, it's 100% > opt- > in, where with coercive you're forced to add casts. That's one difference, but the real difference is that the rules are radically - and the coercive ones are what you'd almost always want to use in real life, while strict almost never is - which means a lot more explicit casts. The most popular conversion in PHP - string -> number - just works. With strict mode, it simply doesn't. Personally, I think that the 'it won't break until you actually flip it on' stance is weak. When people do flip it on (and they'd certainly be encouraged to do so by many people, e.g. your blog post from a few weeks ago) - they're going to see massive breakage which will in turn require massive explicit casting - resulting in much worse code than in the coercive type hints case. > 5. It's full of logical inconsistencies: > > For example, given the following code: > > function foo(bool $abc) {} > > These calls work: > > foo(true); > foo(1); > foo("test"); > > While these fail (note they don't fail on 5.x): > > foo(1.0); > foo(array()); > foo(null); > > Why is `int` accepted for `bool`, but `float` rejected??? Because int is commonly used in boolean context, which cannot be said about float (if you discount the PHP test suite, that is). This patch tries to provide real-world value and support real-world use cases - and blocks ones which are more than likely to be mistakes. The rules are designed to work in the vast majority of cases and support all the sensible conversions. You can always use explicit casting or otherwise refactor your code if you do bump into some edge case - but fact is, you'd bump into a lot less problems than if you flip on strict. > And that's not even mentioning that this has been put to vote without > having > the final version put up for discussion. There were [12 non-voting related > changes in the past 28 > hours](https://wiki.php.net/rfc/coercive_sth?do=revisions). Some of them > are likely trivial tweaks, but some like `allow int/string -> bool > conversion` > are definitely not trivial. I can't actually pull a diff of the changes > due to > errors on wiki.php.net, so I can't tell exactly what was changed... In terms of behavior that's the only thing that changed, and those were discussed publicly over a week ago. Guys, this isn't House Of Cards. Let's stay focused on substance. Zeev --- ## #84564 — Dan Ackroyd — 2015-03-11T18:03:55+00:00 URL: https://externals.io/message/84548#84564 · In reply to: #84557 > I think that going through a transition period ... that ultimately results > in one, consistent language behavior This RFC is explicitly saying that there is stuff that will be need to be changed in the future. Why would anyone upgrade from PHP 5.6 to PHP 70 when there are going to be more changes to the type system? Everyone would wait until that future version of PHP to upgrade and so just have to do a single migration, instead of having to do two migrations? This is clearly worse than the strict STH RFC; with that people can write code that will work on 5.x, 7 and 7.x by just not using scalar type hints. cheers Dan --- ## #84566 — Zeev Suraski — 2015-03-11T18:21:03+00:00 URL: https://externals.io/message/84548#84566 · In reply to: #84564 > -----Original Message----- > From: Dan Ackroyd [mailto:danack@basereality.com] > Sent: Wednesday, March 11, 2015 8:04 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > > > […] > > This RFC is explicitly saying that there is stuff that will be need to be > changed > in the future. Why would anyone upgrade from PHP 5.6 to PHP > 70 when there are going to be more changes to the type system? Because of the huge performance gain? And the many features? And the ability to gradually prepare for future versions softly, like virtually all of our deprecated functionality lifecycle works? > This is clearly worse than the strict STH RFC; with that people can write > code > that will work on 5.x, 7 and 7.x by just not using scalar type hints. That's exactly the same here too. Code that works on 7 will work on 5 - 7 will be more restrictive than 5, but not vice versa, so anything that works on 7, works fine on 5. And you get the benefit of weeding out issues and make your code better for both versions by checking it on 7. Zeev --- ## #84568 — Benoit Schildnecht — 2015-03-11T18:37:25+00:00 URL: https://externals.io/message/84548#84568 · In reply to: #84548 Hi, You are making a very huge mistake, IMHO. By having 2 conflicting RFC, you are taking the risk they both fail. And it won't do any good to the language. While you could have either proposed yours after the STH one if it would have failed, or create a new RFC to make the STH one evolve if it would have succeeded, you decided to act with precipitation. Why did you do this ? I'm kinda sad, upset and anxious. Regards, "Zeev Suraski" a écrit dans le message de groupe de discussion : >The vote on the Coercive Scalar Type Hints is now open for voting. >The latest version of the RFC includes changes discussed on internals@ last week: >1. Accept string->bool and int->bool conversions (false->bool is not supported) >2. Accept leading/trailing spaces in string->number conversions. wiki.php.net/rfc/coercive_sth wiki.php.net/rfc/coercive_sth#vote Thanks! Zeev --- ## #84569 — eli@eliw.com — 2015-03-11T18:46:11+00:00 URL: https://externals.io/message/84548#84569 · In reply to: #84568 Benoit ... actually Anthony's original proposal specifically was designed to be live at the same time as this alternative proposal. And it's even mentioned in the proposal (stating that it would stay open until the 13th or when the alternative proposal voting ended - whichever was later) So this was all 'as planned' there, Eli > Hi, > > You are making a very huge mistake, IMHO. By having 2 conflicting RFC, > you are taking the risk they both fail. And it won't do any good to the > language. > > While you could have either proposed yours after the STH one if it > would have failed, or create a new RFC to make the STH one evolve > if it would have succeeded, you decided to act with precipitation. > Why did you do this ? > > I'm kinda sad, upset and anxious. > > Regards, > > > "Zeev Suraski" a écrit dans le message de groupe de discussion : > > […] > > > […] > week: > > > […] > supported) > > > […] > > > > wiki.php.net/rfc/coercive_sth > > wiki.php.net/rfc/coercive_sth#vote > > > > Thanks! > > > > Zeev > -- | Eli White | http://eliw.com/ | Twitter: EliW | --- ## #84570 — Zeev Suraski — 2015-03-11T18:48:14+00:00 URL: https://externals.io/message/84548#84570 · In reply to: #84568 It was actually Anthony who proposed that I do that. He also proposed that if they both pass, we'll have a vote to choose between them. For a lot of people, the dual mode and coercive STH RFCs aren't a zero sum game. They just want ONE of them to pass to have some sort of scalar type hinting, and almost don't care what it is. These people should vote in favor of both RFCs, if they find both of them acceptable. Rest assured that if I see that they both seem to be failing as we near the end of the voting time, I'll retract the Coercive STH RFC - and I'll actually vote in favor of the dual mode RFC, as much as I think it's bad, so that we have SOME sort of scalar type hinting in 7. Zeev > -----Original Message----- > From: Benoit Schildnecht [mailto:bensor987@neuf.fr] > Sent: Wednesday, March 11, 2015 8:37 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Re: [VOTE][RFC] Coercive Scalar Type Hints > > Hi, > > You are making a very huge mistake, IMHO. By having 2 conflicting RFC, you > are taking the risk they both fail. And it won't do any good to the > language. > > While you could have either proposed yours after the STH one if it would > have failed, or create a new RFC to make the STH one evolve if it would > have > succeeded, you decided to act with precipitation. > Why did you do this ? > > I'm kinda sad, upset and anxious. > > Regards, > > > "Zeev Suraski" a écrit dans le message de groupe de discussion : > > […] > > > […] > week: > > > […] > supported) > > > […] > > > > wiki.php.net/rfc/coercive_sth > > wiki.php.net/rfc/coercive_sth#vote > > > > Thanks! > > > > Zeev > > > -- > To unsubscribe, > visit: > http://www.php.net/unsub.php --- ## #84572 — Leigh — 2015-03-11T19:07:49+00:00 URL: https://externals.io/message/84548#84572 · In reply to: #84569 > Benoit ... actually Anthony's original proposal specifically was > designed to be live at the same time as this alternative proposal. And > it's even mentioned in the proposal (stating that it would stay open > until the 13th or when the alternative proposal voting ended - whichever > was later) > > So this was all 'as planned' there, > Eli Not sure "designed to be live at the same time" is entirely correct. It's more of an honour clause to be invoked in the event of unfortunate circumstances. (With the less honourable option being to lock in all of the votes and declaring ergo sum victor) --- ## #84573 — Pierre Joye — 2015-03-11T20:05:10+00:00 URL: https://externals.io/message/84548#84573 · In reply to: #84548 > > The vote on the Coercive Scalar Type Hints is now open for voting. > > > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) > > 2. Accept leading/trailing spaces in string->number conversions. > > > > wiki.php.net/rfc/coercive_sth > > wiki.php.net/rfc/coercive_sth#vote Voted no for the following reasons: - change default casting, which has been working since years, consistently inconsistent - due to the previous nature of changes, we have no way to be sure we won't break anything badly out there - big changes in the RFC+patch between last discussions and vote. Should not be allowed, can't veto it so voted no > > > Thanks! > > > > Zeev --- ## #84611 — Ole Markus With — 2015-03-12T08:10:09+00:00 URL: https://externals.io/message/84548#84611 · In reply to: #84573 > > > […] > last > > […] > > Voted no for the following reasons: > > - change default casting, which has been working since years, consistently > inconsistent > - due to the previous nature of changes, we have no way to be sure we won't > break anything badly out there > - big changes in the RFC+patch between last discussions and vote. Should > not be allowed, can't veto it so voted no > I changed my vote to no for the same reasons. Cheers, Ole Markus --- ## #84614 — Zeev Suraski — 2015-03-12T08:29:43+00:00 URL: https://externals.io/message/84548#84614 · In reply to: #84611 > -----Original Message----- > From: Ole Markus With [mailto:olemarkus@olemarkus.org] > Sent: Thursday, March 12, 2015 10:10 AM > To: Pierre Joye; Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints > > > > > > […] > > I changed my vote to no for the same reasons. I'm sorry to hear that Ole Markus. I do want to address these concerns: > - change default casting, which has been working since years, > consistently inconsistent > - due to the previous nature of changes, we have no way to be sure we > won't break anything badly out there Casting rules aren't touched - it's rules for internal function arguments that are changed. This has been a key premise of this proposal since the beginning; Contrary to the 2nd statement, we have a pretty good way of knowing it won't break things badly out there - running it with real world apps and our test suite. As the Impact On Real World Applications section suggests (wiki.php.net/rfc/coercive_sth#changes_to_internal_functions) - the real world impact is minimal, since the conversion which are blocked are rarely relied upon in apps. The issues you do get are almost always legitimate issues - with excellent signal to noise ratio. Users would have several YEARS to fix these issues before they become errors and not warnings. Many of the compatibility breakages we've done over the years (and in 7) had / would have a lot farther reaching impact - often with zero end-user gain to show for it. What is being consistently ignored by everyone is the fact that large projects - with the absence of having a good dynamic option - are likely to implement strict project-wide, resulting in WAAAY bigger breakage, since the strict mode does not differentiate between sensible conversions, that have been relied upon in PHP for the last 20 years ("32" -> 32) and nonsensible conversions that are for the most part a side effect of implementation ("100 dogs" -> 100). > - big changes in the RFC+patch between last discussions and vote. > Should not be allowed, can't veto it so voted no There have been NO big changes to the proposal - only two tweaks which I clearly detailed in the Vote email, that have been publicly discussed in detail on internals@ more than a week ago. There is absolutely no rule in the voting RFC that requires a long period of time between the last changes to the RFC and the vote. The mandatory discussion period starts ticking when the RFC is sent to the list, not when the last changes are made to it. Anyone claiming otherwise is misleading, as both the text in wiki.php.net/rfc/voting#discussion_period is clear about when the ticking starts - and on top of that, I can tell you as the person who introduced the mandatory discussion period and wrote that text, that resetting the clock on every change to the RFC was never ever even remotely considered or intended as a requirement. Zeev --- ## #84618 — Lester Caine — 2015-03-12T09:11:06+00:00 URL: https://externals.io/message/84548#84618 · In reply to: #84614 > There have been NO big changes to the proposal - only two tweaks which I > clearly detailed in the Vote email, that have been publicly discussed in > detail on internals@ more than a week ago. Zeev ... being realistic I think that the chances of getting another 48 votes in favour are unlikely as are the chances of blocking the other proposal? The problem here is that a large number of people want type hinting one way or another and there is not a strong enough case being made NOT to bow to that will? So the next problem is perhaps how do we live with a section of the developer world adding hints to well established libraries? During the move to PHP5 one could quite happily write code that continued to work on the majority of PHP4 systems, The move to PHP7 needs the same set of guidelines, so what is currently being championed which will mean that we have to maintain a PHP5 version of a library from day one of PHP7 and what do we avoid in order for PHP code still to run on PHP5? I still have to be convinced that adding a half baked variable check does have a major advantage. YOU have demonstrated the various transfer paths although they lacked the finer detail type checking that already happens in many code bases such as the range of the number passed. The bit I am more concerned about is the further dilution of the docblock annotation as people will adopt type hints in place of the already existing annotation and again we loose a lot more than we gain :( Personally I would much prefer that this was picked up properly again as other RFC's are trying to do, and I feel that answers all of the type hinting ad other static analysis problems that some people seem to think are so important. Expansion of the docblock 'standard' will also allow range of variables to be managed, yet the whole lot can be striped and ignored once one is out of 'design' phase. Is the final endpoint target here that like python, PHP will become a two stage process with compiled versions of user land code? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #84644 — Larry Garfield — 2015-03-12T16:55:27+00:00 URL: https://externals.io/message/84548#84644 · In reply to: #84618 > > > […] > > Zeev ... being realistic I think that the chances of getting another 48 > votes in favour are unlikely as are the chances of blocking the other > proposal? > > The problem here is that a large number of people want type hinting one > way or another and there is not a strong enough case being made NOT to > bow to that will? So the next problem is perhaps how do we live with a > section of the developer world adding hints to well established > libraries? During the move to PHP5 one could quite happily write code > that continued to work on the majority of PHP4 systems, The move to PHP7 > needs the same set of guidelines, so what is currently being championed > which will mean that we have to maintain a PHP5 version of a library > from day one of PHP7 and what do we avoid in order for PHP code still to > run on PHP5? Code with type hints won't be valid on PHP 5 period, no matter what approach we take. Making internal functions pickier about their existing typing doesn't make writing PHP5-compatible code impossible, it just means you have to be more careful about weird and probably-buggy cases like number_format("101 dalmatians"). As Zeev noted, most of the places that these changes caused an issue are likely existing bugs in the first place, so the PHP 5 code would become better by being PHP 7-compatible. > The bit I am more concerned about is the further dilution of the > docblock annotation as people will adopt type hints in place of the > already existing annotation and again we loose a lot more than we gain > :( Personally I would much prefer that this was picked up properly again > as other RFC's are trying to do, and I feel that answers all of the type > hinting ad other static analysis problems that some people seem to think > are so important. Expansion of the docblock 'standard' will also allow > range of variables to be managed, yet the whole lot can be striped and > ignored once one is out of 'design' phase. We don't lose anything by type information moving from a docblock to the method signature itself, and in fact we gain a great deal as has been discussed to death in this thread. We already can have whatever type information you want in docblocks, but that means diddlysquat for the compiler or runtime. This whole paragraph is a red herring. > Is the final endpoint target here that like python, PHP will become a > two stage process with compiled versions of user land code? With an opcache built into core and discussion of it moving into the engine I think that's a given, in practice. That's entirely unrelated to typing, though. --Larry Garfield --- ## #84647 — Lester Caine — 2015-03-12T17:25:21+00:00 URL: https://externals.io/message/84548#84647 · In reply to: #84644 > > > […] > > Code with type hints won't be valid on PHP 5 period, no matter what > approach we take. > > Making internal functions pickier about their existing typing doesn't > make writing PHP5-compatible code impossible, it just means you have to > be more careful about weird and probably-buggy cases like > number_format("101 dalmatians"). As Zeev noted, most of the places that > these changes caused an issue are likely existing bugs in the first > place, so the PHP 5 code would become better by being PHP 7-compatible. If type hinting is NOT used at all, then the code should run on PHP5? The question is just what does one have to avoid to remain PHP5 compatible, and more important just how does one avoid some third party use of it getting in the way. > > […] > > We don't lose anything by type information moving from a docblock to the > method signature itself, and in fact we gain a great deal as has been > discussed to death in this thread. We already can have whatever type > information you want in docblocks, but that means diddlysquat for the > compiler or runtime. This whole paragraph is a red herring. The whole argument about adding type hinting revolves about red herrings. There is nothing stopping someone using static analysis on well written and documented PHP5 code today without affecting everybody elses use of that code. > > […] > > With an opcache built into core and discussion of it moving into the > engine I think that's a given, in practice. That's entirely unrelated to > typing, though. Again much is being made of 'optimizing at compile time' a term which I simply don't recognise. If one has a script that is running ... it's running ... and loading it up with more switches is detracting from performance ... unless there is caching already running? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #84673 — Yasuo Ohgaki — 2015-03-13T09:56:28+00:00 URL: https://externals.io/message/84548#84673 · In reply to: #84548 Hi Zeev, > The latest version of the RFC includes changes discussed on internals@ > last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) > > 2. Accept leading/trailing spaces in string->number conversions. > > > > wiki.php.net/rfc/coercive_sth > > wiki.php.net/rfc/coercive_sth#vote > Status should be changed to "voting". It's "under discussion" now. It's not nice to have 2 modes for new feature while we can do it in a single mode. BC matters, but cleaner and simpler design would bring more benefits for both PHP users and developers. There is enough time to adopt for users. The default behavior is better with this RFC. Weak mode defined in other RFC is too weak to be useful while strict mode seems too restrictive. e.g. 100) trigger_error('Invalid range'); } // Somewhere far from function definition. $num = $GET['num']; // Somewhere far from $num definition. check_num_range($num); // Trying to check validity, int and range. echo 'You have '.$num. ' now
'; // But $num could have any string. // "check_num_range((int)$num)" wouldn't help also. ?> If we decide to have even more stricter hint in the future, we may decide to use "strict" mode with this RFC. This is more preferable path for PHP being type aware. IMHO. For these reasons, I voted "yes" for this, "no" for the other. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #84755 — Levi Morrison — 2015-03-14T02:37:42+00:00 URL: https://externals.io/message/84548#84755 · In reply to: #84548 Zeev, Dmitry and Francois (and anyone), I have a question on a specific conversion. There has been *a lot* of email about scalar types so I apologize if this is answered somewhere already. It seems that `float -> bool` is always disallowed. If I am correct `int -> bool` is permitted for all values (not just 0 and 1), which means that floats which can be converted to integers without dataloss should also be permitted to be booleans. If a specific float can be converted to an int, and all ints can be converted to booleans, then the transitive property should hold for that float to a bool. Am I understanding the current rules correctly? If so can I get more rationale on this? Cheers, Levi Morrison --- ## #84756 — Rasmus Lerdorf — 2015-03-14T02:50:32+00:00 URL: https://externals.io/message/84548#84756 · In reply to: #84755 > It seems that `float -> bool` is always disallowed. If I am correct > `int -> bool` is permitted for all values (not just 0 and 1), which > means that floats which can be converted to integers without dataloss > should also be permitted to be booleans. If a specific float can be > converted to an int, and all ints can be converted to booleans, then > the transitive property should hold for that float to a bool. The problem there is what does "without dataloss" mean? At which precision do you consider there to be no dataloss? -Rasmus --- Next page: https://externals.io/message/84548.md?page=2