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
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!
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
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!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
: stringto 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: stringon 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
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 donot*
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
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 donot*
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
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
--
To unsubscribe, visit: https://www.php.net/unsub.php
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 Thu, Jul 2, 2020 at 11:12 PM Benas IML benas.molis.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 SeliuginasHi 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.0greetings
Benjamin--
To unsubscribe, visit: https://www.php.net/unsub.php
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 benas.molis.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 SeliuginasHi 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
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:
- State that per policy, if the RFC is passed - it would generally go into PHP 9.0.
- 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.
- 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
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
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:
- State that per policy, if the RFC is passed - it would generally go
into PHP 9.0.- 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.- 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
*just let me know if that is a minor change and I'm okay with updating the
RFC right now.
Best regards,
Benas Seliuginas
Hey Zeev,
For me it doesn't really matter if we enforce
voidrules 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 SeliuginasNow, 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:
- State that per policy, if the RFC is passed - it would generally go
into PHP 9.0.- 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.- 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
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
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--
To unsubscribe, visit: https://www.php.net/unsub.php
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
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
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--
To unsubscribe, visit: https://www.php.net/unsub.php
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!
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
Hey Theodore,
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!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
Best regards,
Benas Seliuginas
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
Hey internals,
I have updated the RFC with 2 changes:
- Made the RFC target PHP 9.0 for enforcing
voidrules implicitly. - Added a secondary vote for allowing explicit
voidreturn type declaration.
I will be opening the vote again on Wednesday (July 8th).
Best regards,
Benas
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
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
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
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_voidBest regards,
BenasHey 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--
To unsubscribe, visit: https://www.php.net/unsub.php
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.
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:
- Allow you to omit a return type (and therefore return whatever you want)
- 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
Hey internals,
I have closed the vote. The RFC was declined with 34 in favor and 22
against.
Best regards,
Benas
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