Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void

This is only part of a thread. view whole thread
  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
>