[RFC] [VOTE] Make constructors and destructors return void

  110824
July 2, 2020 21:12 benas.molis.iml@gmail.com (Benas IML)
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
  110826
July 3, 2020 08:39 nicolas.grekas+php@gmail.com (Nicolas Grekas)
> 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
  110829
July 3, 2020 09:08 benas.molis.iml@gmail.com (Benas IML)
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, raaaah!"
> 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
>
  110831
July 3, 2020 09:49 nicolas.grekas+php@gmail.com (Nicolas Grekas)
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
>
  110833
July 3, 2020 10:42 benas.molis.iml@gmail.com (Benas IML)
> > 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
>
  110828
July 3, 2020 09:04 kontakt@beberlei.de (Benjamin Eberlei)
On Thu, Jul 2, 2020 at 11:12 PM Benas IML iml@gmail.com> 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 > >
  110830
July 3, 2020 09:15 benas.molis.iml@gmail.com (Benas IML)
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 <kontakt@beberlei.de> wrote:

> > > On Thu, Jul 2, 2020 at 11:12 PM Benas IML iml@gmail.com> > 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 >> >>
  110832
July 3, 2020 10:26 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Jul 3, 2020 at 11:04 AM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

> On Thu, Jul 2, 2020 at 11:12 PM Benas IML iml@gmail.com> > 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
  110837
July 3, 2020 15:05 zeev@zend.com (Zeev Suraski)
> On 3 Jul 2020, at 13:27, Nikita Popov ppv@gmail.com> 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
  110838
July 3, 2020 15:20 benas.molis.iml@gmail.com (Benas IML)
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 <zeev@zend.com> wrote:

> > > On 3 Jul 2020, at 13:27, Nikita Popov ppv@gmail.com> 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
  110839
July 3, 2020 15:21 benas.molis.iml@gmail.com (Benas IML)
*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 iml@gmail.com> 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 <zeev@zend.com> wrote: > >> >> > On 3 Jul 2020, at 13:27, Nikita Popov ppv@gmail.com> 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 > >
  110834
July 3, 2020 12:47 phpmailinglists@gmail.com (Peter Bowyer)
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 iml@gmail.com> 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 >
  110835
July 3, 2020 14:07 benas.molis.iml@gmail.com (Benas IML)
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 <phpmailinglists@gmail.com> 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 iml@gmail.com> 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 >> >
  110840
July 3, 2020 16:52 theodorejb@outlook.com (Theodore Brown)
On Thu, July 2, 2020 at 4:12 PM Benas IML iml@gmail.com> 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&module=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
  110841
July 3, 2020 17:24 benas.molis.iml@gmail.com (Benas IML)
Hey Theodore,

On Fri, 3 Jul 2020 at 19:52, Theodore Brown <theodorejb@outlook.com> wrote:
> > On Thu, July 2, 2020 at 4:12 PM Benas IML iml@gmail.com> 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&module=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
  110842
July 3, 2020 17:28 benas.molis.iml@gmail.com (Benas IML)
Hey internals,

I closed the vote and will be restarting it tomorrow since the
secondary vote breaks the policy (no BC breaks in minor versions).

I will update the RFC and open it tomorrow (July 4th) again.

Best regards,
Benas Seliuginas
  110854
July 6, 2020 20:06 benas.molis.iml@gmail.com (Benas IML)
Hey internals,

I have updated the RFC with 2 changes:

1. Made the RFC target PHP 9.0 for enforcing `void` rules implicitly.
2. Added a secondary vote for allowing explicit `void` return type declaration.

I will be opening the vote again on Wednesday (July 8th).

Best regards,
Benas

On Fri, 3 Jul 2020 at 00:12, Benas IML iml@gmail.com> 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
  110883
July 8, 2020 20:14 benas.molis.iml@gmail.com (Benas IML)
Hey internals,

I have reopened the voting. It is going to close July 22nd, 2020. I have also
added a "Why allow void return type on constructors/destructors?" section which
I hope internals are going to read and consider before voting. Thanks!

RFC:
https://wiki.php.net/rfc/make_ctor_ret_void

Best regards,
Benas

On Fri, 3 Jul 2020 at 00:12, Benas IML iml@gmail.com> 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
  110894
July 9, 2020 13:51 kontakt@beberlei.de (Benjamin Eberlei)
On Wed, Jul 8, 2020 at 10:15 PM Benas IML iml@gmail.com> wrote:

> Hey internals, > > I have reopened the voting. It is going to close July 22nd, 2020. I have > also > added a "Why allow void return type on constructors/destructors?" section > which > I hope internals are going to read and consider before voting. Thanks! >
I wanted to give a datapoint for my no vote. I think going from forbidding return types on ctors to requiring them to be void is one step to far. Yes, the use-cases for returning something from a constructor are questionable, but why force something that strictly is not something the language should care about, as it can as easily be a coding style topic. For me the RFC vote should be "allow to dcelare return types on constructors/destructors?", then people *can* declare void, but *can* also declare other things, but nothing *must* be done. Then it becomes a question of coding styles enforcing "void" for all constructors of a project for example. I would vote Yes on that.
> RFC: > https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas > > On Fri, 3 Jul 2020 at 00:12, Benas IML iml@gmail.com> 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 > >
  110897
July 9, 2020 14:27 someniatko@gmail.com (someniatko)
> I think going from forbidding > return types on ctors to requiring them to be void is one step to far.
I am afraid you've slightly misunderstood the intention of this RFC. It is proposed that it is impossible to return anything from the constructor, not that you have to add ": void" to it.
  110900
July 9, 2020 15:41 phpmailinglists@gmail.com (Peter Bowyer)
On Thu, 9 Jul 2020 at 14:52, Benjamin Eberlei <kontakt@beberlei.de> wrote:

> For me the RFC vote should be "allow to dcelare return types on > constructors/destructors?", then people *can* declare void, but *can* also > declare other things, but nothing *must* be done. Then it becomes a > question of coding styles enforcing "void" for all constructors of a > project for example. I would vote Yes on that. >
Isn't this close to what the second vote "Allow void return type on constructors/destructors?" does? My understanding is that a "Yes" on this vote will: 1. Allow you to omit a return type (and therefore return whatever you want) 2. Explicitly add void return type This doesn't do exactly what you ask for (to add any return type) but to me is close enough; as these are meant to be void according to the PHP docs, having it as the only explicit return type makes sense to me. Peter
  111142
July 23, 2020 04:43 benas.molis.iml@gmail.com (Benas IML)
Hey internals,

I have closed the vote. The RFC was declined with 34 in favor and 22
against.

Best regards,
Benas

On Fri, Jul 3, 2020, 12:12 AM Benas IML iml@gmail.com> 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 >