# [RFC][Vote] Return Types - Thread: https://externals.io/message/80448 - Original archive: https://news-web.php.net/php.internals/80448 - Started by Levi Morrison on 2015-01-14T09:18:06+00:00 - Messages: 19 - 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 --- ## #80448 — Levi Morrison — 2015-01-14T09:18:06+00:00 URL: https://externals.io/message/80448#80448 Dear Internals, I have moved the Return Types RFC[1] into voting phase. A few changes have happened since it was originally announced but have been covered by discussion. Return types are now invariant. This means a sub-type must declare the same return type as its super-type's method when overriding it. Aliases such as self and parent must resolve to the same type. Also note that picking invariance now does not mean we can't support covariance later. This decision was a trade-off of my time and the projected timeline for PHP 7. I was not confident I could produce an excellent design and implementation in time for PHP 7 if I chose covariance instead. There is no reflection support for return types; another RFC[2] will handle this. Dmitry updated a sizeable chunk of the implementation[3] to work on much more recent master branch. Thanks, Dmitry. I have updated it to work on the latest master version as of the time of this writing and altered one or two things to bring it into line with the RFC. The voting period will end during the evening of 2015-01-23 in UTC-7. This period is around ten days, which I hope is enough time for everyone to be able to vote. [1]: https://wiki.php.net/rfc/return_types#vote [2]: https://wiki.php.net/rfc/reflectionparameter.typehint [3]: https://github.com/php/php-src/pull/997 --- ## #80477 — Marcio Almada — 2015-01-14T19:04:20+00:00 URL: https://externals.io/message/80448#80477 · In reply to: #80448 Hi Levi, It's nice to see this RFC in voting phase again so quickly :) I just have one question. Since we had some changes in the implementation will the previous votes be discarded? 2015-01-14 6:18 GMT-03:00 Levi Morrison : > Dear Internals, > > I have moved the Return Types RFC[1] into voting phase. A few changes > have happened since it was originally announced but have been covered > by discussion. > > Return types are now invariant. This means a sub-type must declare the > same return type as its super-type's method when overriding it. > Aliases such as self and parent must resolve to the same type. > > Also note that picking invariance now does not mean we can't support > covariance later. This decision was a trade-off of my time and the > projected timeline for PHP 7. I was not confident I could produce an > excellent design and implementation in time for PHP 7 if I chose > covariance instead. > > There is no reflection support for return types; another RFC[2] will > handle this. > > Dmitry updated a sizeable chunk of the implementation[3] to work on > much more recent master branch. Thanks, Dmitry. I have updated it to > work on the latest master version as of the time of this writing and > altered one or two things to bring it into line with the RFC. > > The voting period will end during the evening of 2015-01-23 in UTC-7. > This period is around ten days, which I hope is enough time for > everyone to be able to vote. > > [1]: https://wiki.php.net/rfc/return_types#vote > [2]: https://wiki.php.net/rfc/reflectionparameter.typehint > [3]: https://github.com/php/php-src/pull/997 --- ## #80485 — Levi Morrison — 2015-01-14T20:08:26+00:00 URL: https://externals.io/message/80448#80485 · In reply to: #80477 > Hi Levi, > > It's nice to see this RFC in voting phase again so quickly :) I just have > one question. Since we had some changes in the implementation will the > previous votes be discarded? > > 2015-01-14 6:18 GMT-03:00 Levi Morrison : > > > […] The previous votes were discarded, yes. --- ## #80619 — Yasuo Ohgaki — 2015-01-16T07:46:49+00:00 URL: https://externals.io/message/80448#80619 · In reply to: #80448 Hi Levi, > [1]: https://wiki.php.net/rfc/return_types#vote > I read the RFC quickly and could not find closure syntax example. function():array use ($var) {} or function() use ($var): array {} which one will be the syntax? I suppose first one will be the syntax, though. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #80620 — Simon J Welsh — 2015-01-16T07:53:05+00:00 URL: https://externals.io/message/80448#80620 · In reply to: #80619 > > > Hi Levi, > > > > > […] > > I read the RFC quickly and could not find closure syntax example. > > function():array use ($var) {} > > or > > function() use ($var): array {} > > which one will be the syntax? I suppose first one will be the syntax, > though. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net The tests have it after the use(): https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9 This was discussed in depth a couple of times in the related threads. --- Simon Welsh Admin of http://91carriage.com/ – Specialised SilverStripe hosting --- ## #80663 — Yasuo Ohgaki — 2015-01-16T21:36:23+00:00 URL: https://externals.io/message/80448#80663 · In reply to: #80620 Hi Simon and Levi, > The tests have it after the use(): > https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9 > > This was discussed in depth a couple of times in the related threads. > Thank you for the information. It should be in the RFC. IMHO. I feels natural to have type spec after function parameter definition rather than after "use". Anyway, I looked HACK/HHVM manual http://docs.hhvm.com/manual/en/index.php and couldn't find the syntax. If it's the same, then it should be OK. I'm just making sure before voting. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #80683 — Pierre Joye — 2015-01-17T06:05:24+00:00 URL: https://externals.io/message/80448#80683 · In reply to: #80663 > Hi Simon and Levi, > > > > > […] > > Thank you for the information. It should be in the RFC. IMHO. > I feels natural to have type spec after function parameter definition > rather than > after "use". Please do not change the RFC during votes phase, or re start it. If many of the voters feel like they were voted on something different of what is being discussed here, it may be a good thing to restart it. However I think we all understood it as it is described in this thread. Let update it after the votes or for the docs. --- ## #80711 — Yasuo Ohgaki — 2015-01-17T23:42:14+00:00 URL: https://externals.io/message/80448#80711 · In reply to: #80683 Hi Pierre and Levi, > > > […] > wrote: > > […] > https://github.com/php/php-src/pull/997/files#diff-e306c6e99612ba59b00a4fe435b287e5R9 > > […] > > Please do not change the RFC during votes phase, or re start it. > > If many of the voters feel like they were voted on something different > of what is being discussed here, it may be a good thing to restart it. > However I think we all understood it as it is described in this > thread. Let update it after the votes or for the docs. Sounds good to me. Let's update the RFC after vote. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #80748 — Levi Morrison — 2015-01-18T16:53:27+00:00 URL: https://externals.io/message/80448#80748 · In reply to: #80711 > Hi Pierre and Levi, > > > > […] > > > Sounds good to me. > Let's update the RFC after vote. According to the previous discussion the return type goes after the use statement, and this is how it is implemented. There has not been an unintentional mistake here. If you disagree with that decision I am open to discussing it again. Since it isn't actually mentioned in the RFC (which was an oversight, I apologize) I'm not sure we'd have to revote on it. Anyone else have an opinion on this? --- ## #80749 — Pierre Joye — 2015-01-18T16:55:55+00:00 URL: https://externals.io/message/80448#80749 · In reply to: #80748 > > > […] > > According to the previous discussion the return type goes after the > use statement, and this is how it is implemented. There has not been > an unintentional mistake here. > > If you disagree with that decision I am open to discussing it again. > Since it isn't actually mentioned in the RFC (which was an oversight, > I apologize) I'm not sure we'd have to revote on it. Anyone else have > an opinion on this? Addint/editing it means a re vote. I do not think it is necessary at is pretty clear, or I think it is. At the very least, let wait after the vote ended, to see if complains will be raised. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #80755 — Levi Morrison — 2015-01-18T17:33:54+00:00 URL: https://externals.io/message/80448#80755 · In reply to: #80749 > > > […] > > Addint/editing it means a re vote. I did not mean editing it during vote; I meant that since the RFC does not actually address this point it isn't technically included in the vote. This means that if it passes we could alter this behavior if desired while still being true to the vote. --- ## #80756 — Andrea Faulds — 2015-01-18T18:21:50+00:00 URL: https://externals.io/message/80448#80756 · In reply to: #80749 Hey Pierre, > > > Addint/editing it means a re vote. I don’t think this is always true. For minor changes to the RFC text that provide clarifications and do not change the actual proposal, there’s no problem with editing during voting. In this case, the position of the return type in the anonymous function syntax isn’t a new detail of the proposal, as it was already in the patch. Adding it to the RFC would just help clear things up. Thanks. -- Andrea Faulds http://ajf.me/ --- ## #80758 — Pierre Joye — 2015-01-18T18:52:42+00:00 URL: https://externals.io/message/80448#80758 · In reply to: #80756 > > Hey Pierre, > > > […] > > I don’t think this is always true. For minor changes to the RFC text that provide clarifications and do not change the actual proposal, there’s no problem with editing during voting. > > In this case, the position of the return type in the anonymous function syntax isn’t a new detail of the proposal, as it was already in the patch. Adding it to the RFC would just help clear things up. If the RFC is not clear, it should not proposed to vote on in the 1st place. There must be no edit during the vote phase. It has abused too often already. Be ready or wait until you are. > Thanks. > > -- > Andrea Faulds > http://ajf.me/ --- ## #80996 — Pascal Martin — 2015-01-22T22:29:44+00:00 URL: https://externals.io/message/80448#80996 · In reply to: #80448 > I have moved the Return Types RFC[1] into voting phase. A few changes > have happened since it was originally announced but have been covered > by discussion. Hi, After discussing this RFC between members of AFUP, we are +1. Once this is done, extending it to nullable types and scalar hints could be interesting too -- if the corresponding RFCs pass, of course. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ --- ## #81060 — Levi Morrison — 2015-01-24T00:06:06+00:00 URL: https://externals.io/message/80448#81060 · In reply to: #80996 As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will close in a few hours. I want to thank everyone who has voted so far, and encourage anyone who has not yet voted to do so. --- ## #81069 — Levi Morrison — 2015-01-24T05:01:57+00:00 URL: https://externals.io/message/80448#81069 · In reply to: #81060 > As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will > close in a few hours. I want to thank everyone who has voted so far, > and encourage anyone who has not yet voted to do so. I have close the voting. It has passed with a vote of 47 to 3. I will update the patch to the latest master and then ping Dmitry to do a final pass before merging it into master. --- ## #81259 — Dmitry Stogov — 2015-01-27T20:13:35+00:00 URL: https://externals.io/message/80448#81259 · In reply to: #81069 Hi Levi, Do you like me to make final check and merge your pull request? We need it :) Thanks. Dmitry. > > > […] > > I have close the voting. It has passed with a vote of 47 to 3. > > I will update the patch to the latest master and then ping Dmitry to > do a final pass before merging it into master. --- ## #81270 — Levi Morrison — 2015-01-28T01:37:10+00:00 URL: https://externals.io/message/80448#81270 · In reply to: #81259 Dmitry, I updated the patch to latest master and (seem to have) fixed a memory issue with it. However when I pushed it back up Travis had a lot of failing return types tests. Could you (and anyone else willing) pull it and see if you are getting failing tests for release and debug builds? Cheers, Levi Morrison > Hi Levi, > > Do you like me to make final check and merge your pull request? > We need it :) > > Thanks. Dmitry. > > > > > […] --- ## #81274 — Dmitry Stogov — 2015-01-28T01:58:34+00:00 URL: https://externals.io/message/80448#81274 · In reply to: #81270 No problem, I'll verify if (fix if necessary) and commit. Thanks. Dmitry. > Dmitry, > > I updated the patch to latest master and (seem to have) fixed a memory > issue with it. However when I pushed it back up Travis had a lot of failing > return types tests. Could you (and anyone else willing) pull it and see if > you are getting failing tests for release and debug builds? > > Cheers, > > Levi Morrison > > > > > > […]