Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey Theodore, On Fri, 3 Jul 2020 at 19:52, Theodore Brown wrote: > > On Thu, July 2, 2020 at 4:12 PM Benas IML wrote: > > > I have opened the voting for the RFC, let's hope everything is going > > to be smooth :). If you have any other questions, let me know! > > > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Hi Benas, > > Thanks for your work on this. I'm in favor of deprecating the ability > to return values from constructors and destructors to align their > behavior with the documentation and how most other languages work. > > Unfortunately, the RFC doesn't provide an option to vote just for > this. Instead it only offers combining the deprecation with a new Quite honestly, this would also question why the "Ensure correct magic methods' signature" RFC was introduced in the first place since it also limited some magic methods to only having a single type (if declared) i. e. `__toString()` might only have `string` return type. > option for developers to choose whether constructors and destructors > are explicitly typed as void. > > But what will be the benefit of typing constructors/destructors as > void when this is the only allowed type, and after the deprecation > adding the type won't change anything anyway? It will lead to a > situation where some projects require the explicit type, others > require not having an explicit type, Same with the `void` return type in general. If you go onto GitHub, some projects have an explicit `: void`, others not. Every single feature is used by some group of people and isn't used by another. This is again, a rather subjective thing. ...and for more arguments, please read Larry's, Rowan's and my replies on the original discussion thread since I did go into mor edetail on this matter. > and the rest have a mishmash of > the two. This will lead to further bikeshedding in projects and > unnecessary code changes. If this was the case, we would also see a ton of tabs and spaces' mixed together in projects but we don't. > Allowing an explicit void type on constructors is also at variance > with other languages. For example, TypeScript does not allow > constructor return type declarations. [1] Nor does C# [2], nor does > Java. [3] Likewise, C++ constructors do not allow an explicit return > type [4], nor do initializers in Swift [5] and Kotlin [6]. ...and also please call constructors/destructors directly in any of those languages like you can in PHP. I. e. `$object->__construct()` and `$object->__destruct()`. Unlike in any of those languages, constructors also don't look or behave like constructors in PHP so comparing those languages with PHP doesn't make a whole lot of sense. > For these two reasons, I voted no on this RFC. I think it would be > fine to deprecate the ability to return values from constructors/ > destructors, though, and this could happen in PHP 8.1 if there isn't > time for it to land in PHP 8.0. > > Best regards, > Theodore > > [1]: > https://www.typescriptlang.org/play/?target=7=5#code/MYGwhgzhAEBiD29oG8BQ0PWPAdhALgE4Cuw+8hAFAJQBc0AbvAJYAmK6mAvqj0A > [2]: > https://www.c-sharpcorner.com/article/different-types-of-constructor-in-c-sharp/ > [3]: https://docs.oracle.com/javase/tutorial/java/javaOO/constructors.html > [4]: https://docs.microsoft.com/en-us/cpp/cpp/constructors-cpp?view=vs-2019 > [5]: https://docs.swift.org/swift-book/LanguageGuide/Initialization.html > [6]: https://kotlinlang.org/docs/reference/classes.html#constructors Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
On Thu, July 2, 2020 at 4:12 PM Benas IML wrote: > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other questions, let me know! > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void Hi Benas, Thanks for your work on this. I'm in favor of deprecating the ability to return values from constructors and destructors to align their behavior with the documentation and how most other languages work. Unfortunately, the RFC doesn't provide an option to vote just for this. Instead it only offers combining the deprecation with a new option for developers to choose whether constructors and destructors are explicitly typed as void. But what will be the benefit of typing constructors/destructors as void when this is the only allowed type, and after the deprecation adding the type won't change anything anyway? It will lead to a situation where some projects require the explicit type, others require not having an explicit type, and the rest have a mishmash of the two. This will lead to further bikeshedding in projects and unnecessary code changes. Allowing an explicit void type on constructors is also at variance with other languages. For example, TypeScript does not allow constructor return type declarations. [1] Nor does C# [2], nor does Java. [3] Likewise, C++ constructors do not allow an explicit return type [4], nor do initializers in Swift [5] and Kotlin [6]. For these two reasons, I voted no on this RFC. I think it would be fine to deprecate the ability to return values from constructors/ destructors, though, and this could happen in PHP 8.1 if there isn't time for it to land in PHP 8.0. Best regards, Theodore [1]: https://www.typescriptlang.org/play/?target=7=5#code/MYGwhgzhAEBiD29oG8BQ0PWPAdhALgE4Cuw+8hAFAJQBc0AbvAJYAmK6mAvqj0A [2]: https://www.c-sharpcorner.com/article/different-types-of-constructor-in-c-sharp/ [3]: https://docs.oracle.com/javase/tutorial/java/javaOO/constructors.html [4]: https://docs.microsoft.com/en-us/cpp/cpp/constructors-cpp?view=vs-2019 [5]: https://docs.swift.org/swift-book/LanguageGuide/Initialization.html [6]: https://kotlinlang.org/docs/reference/classes.html#constructors -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
*just let me know if that is a minor change and I'm okay with updating the RFC right now. Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 6:20 PM Benas IML wrote: > Hey Zeev, > > For me it doesn't really matter if we enforce `void` rules implicitly in > PHP 8.1 or PHP 9.0. Just that we do at some point. > > Thus, I'm okay with closing the secondary vote and updating the RFC to > mention only PHP 9.0 (and not PHP 8.1). > > Best regards, > Benas Seliuginas > > On Fri, Jul 3, 2020, 6:05 PM Zeev Suraski wrote: > >> >> > On 3 Jul 2020, at 13:27, Nikita Popov wrote: >> > >> > Now, whether this RFC actually makes a sufficient case to disregard >> policy >> > here is a different question, and at the discretion of the voters. >> >> I think this is key here (the first part, not the second). >> >> It doesn’t seem as if the RFC makes any case at all why it urgent to >> enforce this compatibility break outside of the standard policy. In fact, >> unless I’m missing something, it doesn’t attempt to tackle that question at >> all, and portrays it as a simple choice between two equal options that are >> up to personal preference. That is not the case - our standard policy is >> an outward facing contract, which we should be very wary of breaking - and >> at the very least do while taking a very informed, measured decision. >> >> We can not assume that all voters fully understand the implications of >> breaking the policy, or even that this would be breaking policy at all, >> given that it’s not even mentioned in the RFC. >> >> As such, I do think the current state of the RFC is somewhat problematic, >> and to actually consider introducing it into 8.1, the RFC requires 3 >> amendments: >> >> 1. State that per policy, if the RFC is passed - it would generally go >> into PHP 9.0. >> 2. Make the case of why the RFC author believes it’s important to do it >> in 8.1 and not wait for 9.0 per our public-facing policy. >> 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, >> despite our compatibility policy”, and turn it into a clear Yes/No question >> that clearly requires a 2/3 majority. Since technically it might be an >> issue, perhaps we can stick with the current wording, but still make it >> clear that for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. >> >> I think those are fairly minor amendments that can be done without >> restarting the vote, given where it’s at. >> >> Zeev > >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey Zeev, For me it doesn't really matter if we enforce `void` rules implicitly in PHP 8.1 or PHP 9.0. Just that we do at some point. Thus, I'm okay with closing the secondary vote and updating the RFC to mention only PHP 9.0 (and not PHP 8.1). Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 6:05 PM Zeev Suraski wrote: > > > On 3 Jul 2020, at 13:27, Nikita Popov wrote: > > > > Now, whether this RFC actually makes a sufficient case to disregard > policy > > here is a different question, and at the discretion of the voters. > > I think this is key here (the first part, not the second). > > It doesn’t seem as if the RFC makes any case at all why it urgent to > enforce this compatibility break outside of the standard policy. In fact, > unless I’m missing something, it doesn’t attempt to tackle that question at > all, and portrays it as a simple choice between two equal options that are > up to personal preference. That is not the case - our standard policy is > an outward facing contract, which we should be very wary of breaking - and > at the very least do while taking a very informed, measured decision. > > We can not assume that all voters fully understand the implications of > breaking the policy, or even that this would be breaking policy at all, > given that it’s not even mentioned in the RFC. > > As such, I do think the current state of the RFC is somewhat problematic, > and to actually consider introducing it into 8.1, the RFC requires 3 > amendments: > > 1. State that per policy, if the RFC is passed - it would generally go > into PHP 9.0. > 2. Make the case of why the RFC author believes it’s important to do it > in 8.1 and not wait for 9.0 per our public-facing policy. > 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, despite > our compatibility policy”, and turn it into a clear Yes/No question that > clearly requires a 2/3 majority. Since technically it might be an issue, > perhaps we can stick with the current wording, but still make it clear that > for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. > > I think those are fairly minor amendments that can be done without > restarting the vote, given where it’s at. > > Zeev
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
> On 3 Jul 2020, at 13:27, Nikita Popov wrote: > > Now, whether this RFC actually makes a sufficient case to disregard policy > here is a different question, and at the discretion of the voters. I think this is key here (the first part, not the second). It doesn’t seem as if the RFC makes any case at all why it urgent to enforce this compatibility break outside of the standard policy. In fact, unless I’m missing something, it doesn’t attempt to tackle that question at all, and portrays it as a simple choice between two equal options that are up to personal preference. That is not the case - our standard policy is an outward facing contract, which we should be very wary of breaking - and at the very least do while taking a very informed, measured decision. We can not assume that all voters fully understand the implications of breaking the policy, or even that this would be breaking policy at all, given that it’s not even mentioned in the RFC. As such, I do think the current state of the RFC is somewhat problematic, and to actually consider introducing it into 8.1, the RFC requires 3 amendments: 1. State that per policy, if the RFC is passed - it would generally go into PHP 9.0. 2. Make the case of why the RFC author believes it’s important to do it in 8.1 and not wait for 9.0 per our public-facing policy. 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, despite our compatibility policy”, and turn it into a clear Yes/No question that clearly requires a 2/3 majority. Since technically it might be an issue, perhaps we can stick with the current wording, but still make it clear that for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. I think those are fairly minor amendments that can be done without restarting the vote, given where it’s at. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey, Most of the internals who voted no, as far as I know, did so due to subjective reasons (i. e. don't want to allow declaring constructors/destructors as `void`). I don't think that should affect on what you believe is a change for better or for worse. As I mentioned before, it doesn't make much sense to allow `__clone` to be declared as `void` and make constructors/destructors an exception. As for the BC break, yes, only people who return something from a constructor/destructor are in trouble and will get a deprecation warning in PHP 8.0. Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 3:47 PM Peter Bowyer wrote: > Hi, > > I have voted in favour, but enough people I respect have voted against to > make me reconsider. > > My understanding is the changes will only cause problems to people who > have returned something from __construct() or __destruct(). As people > shouldn't have done this, IMO it is a smaller BC issue than the BC break > that would have been caused if the proposed #[] attribute syntax had been > chosen. > > Peter > > On Thu, 2 Jul 2020 at 22:12, Benas IML wrote: > >> Hey internals, >> >> I have opened the voting for the RFC, let's hope everything is going >> to be smooth :). If you have any other questions, let me know! >> >> RFC: https://wiki.php.net/rfc/make_ctor_ret_void >> >> Best regards, >> Benas Seliuginas >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hi, I have voted in favour, but enough people I respect have voted against to make me reconsider. My understanding is the changes will only cause problems to people who have returned something from __construct() or __destruct(). As people shouldn't have done this, IMO it is a smaller BC issue than the BC break that would have been caused if the proposed #[] attribute syntax had been chosen. Peter On Thu, 2 Jul 2020 at 22:12, Benas IML wrote: > Hey internals, > > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other questions, let me know! > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
> > I think that Larry's and Rowan's replies on the original discussion thread >> really well explained as to why it makes sense to allow an explicit `void` >> return type, so I'll just quote them instead ;) >> >> Larry: >> > I see this in the same category as __toString(). >> > > I read those yes, but there are subtle yet critical differences to me: > > in PHP < 8, 1. the return-type of __toString is already enforced by the > engine (just not by the type-system, but the end result is the same) and 2. > it is already allowed to add the "string" return type to the method. > > for constructors/destructors, neither 1. nor 2. are true: they *do*not* > allow any return type and they don't check the return value. > > This means that the change on __toString is mostly transparent (only the > exact error message is different), while the proposed change is not. It > will have a cost for the community, and my opinion is that this cost is not > worth it. > Well, for `__clone` neither 1 nor 2 are true as well. But as of PHP 8.0 it will be allowed to declare an explicit `void` return type on `__clone`. Thus, this will have a higher cost for the community since this behavior will be quite inconsistent with constructors/destructors which do not allow to declare an explicit return type. > > Any constructor returning non-void right now is Doing It Wrong(tm) >> > > That's precisely what I read as "gratuitous strictness" (no offense to > anyone, I respect this opinion.) > Especially when this might become "enforced". > That is rather subjective. Adding an explicit `void` return type allows to clearly show developer's intention to not return values from a constructor/destructor. While some people might not see any value in this, I personally do (and many others too). Moreover, as mentioned before, adding an explicit `void` return type causes the check to already be done in PHP 8.0. Which otherwise implicitly will only be done in PHP 8.1/9.0. > > >> Since some internals told me that PHP doesn't follow semver strictly, it >> would make sense to enforce the check in PHP 8.1 already. >> > > I invite you to read https://wiki.php.net/rfc/releaseprocess where this > is detailed. > Here is the relevant excerpt: "x.y.z to x.y+1.z" => "Backward > compatibility must be kept". > > A dedicated vote in a specific RFC cannot overrule this policy AFAIK. > See Nikita's reply. But if more internals find this controversial, I can close the secondary vote, that's okay with me. > Thanks for your answer, > Nicolas > Best regards, Benas >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
On Fri, Jul 3, 2020 at 11:04 AM Benjamin Eberlei wrote: > On Thu, Jul 2, 2020 at 11:12 PM Benas IML > wrote: > > > Hey internals, > > > > I have opened the voting for the RFC, let's hope everything is going > > to be smooth :). If you have any other questions, let me know! > > > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > > > Best regards, > > Benas Seliuginas > > > > Hi Benas, > > I wanted to raise what I believe is an issue with the secondary vote going > against PHP policy to introduce a BC break in 8.1, I would imagine policy > overrules voting decision here and it wouldn't matter what people voted > for, it will only be removed at the earliest in 9.0 > To answer the policy question: RFCs can override or change general policy -- after all, policy is decided through the RFC process itself. To give a precedent where this happened for a "pure" BC break: https://wiki.php.net/rfc/too_few_args But more generally, many RFCs will have "minor" BC breaks as part of a larger proposal, and RFC acceptance also always implies that we consider those BC breaks acceptable for the targeted PHP version. Now, whether this RFC actually makes a sufficient case to disregard policy here is a different question, and at the discretion of the voters. Regards, Nikita
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
I think that Larry's and Rowan's replies on the original discussion thread > really well explained as to why it makes sense to allow an explicit `void` > return type, so I'll just quote them instead ;) > > Larry: > > I see this in the same category as __toString(). > I read those yes, but there are subtle yet critical differences to me: in PHP < 8, 1. the return-type of __toString is already enforced by the engine (just not by the type-system, but the end result is the same) and 2. it is already allowed to add the "string" return type to the method. for constructors/destructors, neither 1. nor 2. are true: they *do*not* allow any return type and they don't check the return value. This means that the change on __toString is mostly transparent (only the exact error message is different), while the proposed change is not. It will have a cost for the community, and my opinion is that this cost is not worth it. > Any constructor returning non-void right now is Doing It Wrong(tm) > That's precisely what I read as "gratuitous strictness" (no offense to anyone, I respect this opinion.) Especially when this might become "enforced". > Since some internals told me that PHP doesn't follow semver strictly, it > would make sense to enforce the check in PHP 8.1 already. > I invite you to read https://wiki.php.net/rfc/releaseprocess where this is detailed. Here is the relevant excerpt: "x.y.z to x.y+1.z" => "Backward compatibility must be kept". A dedicated vote in a specific RFC cannot overrule this policy AFAIK. Thanks for your answer, Nicolas >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey Benjamin, Some internals told me that PHP doesn't follow semver strictly and it should be okay to enforce `void` rules in PHP 8.1 already. Naturally, I raised that issue on the mailing list but got no replies. So, I have put that question as a secondary vote instead. By the way, is there any particular reason you voted no? If there are any questions, let me know. Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 12:04 PM Benjamin Eberlei wrote: > > > On Thu, Jul 2, 2020 at 11:12 PM Benas IML > wrote: > >> Hey internals, >> >> I have opened the voting for the RFC, let's hope everything is going >> to be smooth :). If you have any other questions, let me know! >> >> RFC: https://wiki.php.net/rfc/make_ctor_ret_void >> >> Best regards, >> Benas Seliuginas >> > > Hi Benas, > > I wanted to raise what I believe is an issue with the secondary vote going > against PHP policy to introduce a BC break in 8.1, I would imagine policy > overrules voting decision here and it wouldn't matter what people voted > for, it will only be removed at the earliest in 9.0 > > greetings > Benjamin > > >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >>
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey Nicolas, Hey internals, >> >> I have opened the voting for the RFC, let's hope everything is going >> to be smooth :). If you have any other questions, let me know! >> >> RFC: https://wiki.php.net/rfc/make_ctor_ret_void >> > > Hi Benas, > > I voted "no" to the RFC because to me adding "void" to constructor and > destructor don't add any value: the semantics of these functions are > totally defined. Annotating the code with "void" is duplicate information. > I think that Larry's and Rowan's replies on the original discussion thread really well explained as to why it makes sense to allow an explicit `void` return type, so I'll just quote them instead ;) Larry: > I see this in the same category as __toString(). > Adding `: string` to that method provides exactly zero additional information. You know it's going to return a string. That's it's whole purpose. On the off chance someone is returning a non-string right now, they're very clearly Doing It Wrong(tm). However, the stringable RFC added the ability to put `: string` on the method in order to be clearer, more explicit, and to not annoy type fans who are like "Ah, I've typed every one of my methods... except this one, because I can't, rh!" > I see this as the same for constructors. Any constructor returning non-void right now is Doing It Wrong(tm), and you know that going in. But being able to make the obvious explicit still has its advantages, both for documentation and for consistency. Rowan: > As long as it's possible to return things from constructors, then it is > "obvious" that a given constructor is void only in the same way that it > is "obvious" that a method called "convertToArray" returns an array. I > would be surprised if any style guide would forbid writing "public > function convertToArray(): array", so would be equally surprised to see > one forbid writing "public function __construct(): void". In both cases, > the extra marker takes the reader from 99% certain to 100%. Another thing to consider is that the explicit `: void` declaration causes the check to be enforced in PHP 8.0. Meanwhile, the implicit check will only be done in PHP 8.1/9.0 (depending on the secondary vote). best this can do is open another code-style bikeshed war. About forbidding > the functions from returning anything, I don't understand why this would > improve the overall quality of anything. To me, this looks like gratuitous > strictness. > Quite honestly, every feature/change in PHP results in some kind of a code-style war. It is not possible to be "politically" neutral. Moreover, allowing `__clone` (as of "Ensure correct magic methods' signature" RFC) to have an explicit `void` return type but disallowing that for constructors/destructors doesn't make much sense. In fact, that is more likely going to create a code style war since not allowing ctors/dtors to have an explicit type would be inconsistent. `__construct` and `__clone` work in a similar fashion yet `__clone` can have an explicit `void` return type and `__construct` - does not. I also don't understand the secondary vote: enforcing "void rules" in 8.1 > is a not-allowed BC break. This can only target 9.0 to me, there can be no > discussion about it in a specific RFC. Or did I miss something? > Since some internals told me that PHP doesn't follow semver strictly, it would make sense to enforce the check in PHP 8.1 already. I raised that question in the original thread but didn't get any replies on that matter. Thus, I have put this as a secondary vote. This is just my opinion on the matter of course. Thanks for contributing to > PHP. > ...and a highly appreciated one, thanks! Nicolas > Best regards, Benas Seliuginas >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
On Thu, Jul 2, 2020 at 11:12 PM Benas IML wrote: > Hey internals, > > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other questions, let me know! > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas > Hi Benas, I wanted to raise what I believe is an issue with the secondary vote going against PHP policy to introduce a BC break in 8.1, I would imagine policy overrules voting decision here and it wouldn't matter what people voted for, it will only be removed at the earliest in 9.0 greetings Benjamin > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
> Hey internals, > > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other questions, let me know! > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > Hi Benas, I voted "no" to the RFC because to me adding "void" to constructor and destructor don't add any value: the semantics of these functions are totally defined. Annotating the code with "void" is duplicate information. The best this can do is open another code-style bikeshed war. About forbidding the functions from returning anything, I don't understand why this would improve the overall quality of anything. To me, this looks like gratuitous strictness. I also don't understand the secondary vote: enforcing "void rules" in 8.1 is a not-allowed BC break. This can only target 9.0 to me, there can be no discussion about it in a specific RFC. Or did I miss something? This is just my opinion on the matter of course. Thanks for contributing to PHP. Nicolas
