[RFC] Allow void return type variance

6 years ago by netmo.php@gmail.com — view source — reply

unread

Hello PHPeeps!

Recent events convinced me to write this RFC :P

Please have a read here https://wiki.php.net/rfc/allow-void-variance

I am targeting all the supported PHP versions because this is mainly to
placate the discontent that arised by PHPUnit enforcing its users to use
void, so waiting 7.4 doesn't make much sense.

FTR this is an improvement regardless of PHPUnit, and it's IMO a very
reasonable change.

Thank you for your time.

Wes

6 years ago by Claude Pache — view source — reply

unread

Le 4 févr. 2019 à 04:22, Wes netmo.php@gmail.com a écrit :

Hello PHPeeps!

Recent events convinced me to write this RFC :P

Please have a read here https://wiki.php.net/rfc/allow-void-variance

I am targeting all the supported PHP versions because this is mainly to
placate the discontent that arised by PHPUnit enforcing its users to use
void, so waiting 7.4 doesn't make much sense.

FTR this is an improvement regardless of PHPUnit, and it's IMO a very
reasonable change.

Thank you for your time.

Wes

The RFC says: “Changing from void to something else is very probably a bad idea, but PHP should not enforce void in subclasses just on that basis.” — If it is “very probably” a bad idea, why do people want to do that? What are the use cases? (Sorry, I’ve not followed the “recent events” you alludes to.)

—Claude

6 years ago by netmo.php@gmail.com — view source — reply

unread

Hi!

PHPUnit 8 changed e.g. function setUp(){} to function setUp(): void{} and a lot of people did not like being forced to do the same on
their setUp().

The issue is not PHPUnit adding void, but PHP forcing void even when
it's not necessary. If PHPUnit wants to use void but inheritors don't want
to, it should just be possible.

"probably a bad idea" is opinionated, in reality there is no provable
reason to disallow it, from a pure type-theory standpoint.

6 years ago by Girgias — view source — reply

unread

Isn't this "fixed" with the Covariance/Contravariance RFC which has been
voted recently

George P. Banyard

Hi!

PHPUnit 8 changed e.g. function setUp(){} to function setUp(): void{} and a lot of people did not like being forced to do the same on
their setUp().

The issue is not PHPUnit adding void, but PHP forcing void even when
it's not necessary. If PHPUnit wants to use void but inheritors don't want
to, it should just be possible.

"probably a bad idea" is opinionated, in reality there is no provable
reason to disallow it, from a pure type-theory standpoint.

6 years ago by netmo.php@gmail.com — view source — reply

unread

Nope, it's not. https://3v4l.org/N4LNb It should've been fixed.
Indeed, many people expected it to work already.

6 years ago by Girgias — view source — reply

unread

This is normal the Covariance/Contravariance is coming in PHP 7.4 not
before.
This RFC would also target PHP 7.4 so I don't see how this RFC would change
the PHPUnit problem.

George P. Banyard

Nope, it's not. https://3v4l.org/N4LNb It should've been fixed.
Indeed, many people expected it to work already.

6 years ago by netmo.php@gmail.com — view source — reply

unread

Covariance from no-type is already supported, since 7.0
https://3v4l.org/I1hZs

6 years ago by Girgias — view source — reply

unread

I know this, I am talking about this RFC
https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
Which has been voted and implementation is being worked on a GitHub PR:
https://github.com/php/php-src/pull/3732

Your proposal doesn't bring anything new to the table that this RFC does.
Moreover, your RFC targets the same PHP version as the
covariant/contravariant RFC.

So like said before the issue which your RFC tries to address is already
being fixed.

Also, there is no need to upgrade to PHPUnit 8 and if people want to there
is a PHP_CS_FIXER sniff which can add void return types.
Namely: void_return

George P. Banyard

Covariance from no-type is already supported, since 7.0
https://3v4l.org/I1hZs

6 years ago by netmo.php@gmail.com — view source — reply

unread

I know this too. I am often in touch with Levi and void variance is not
covered by his RFC
As a matter of fact, if you try to compile that PR void will behave exactly
like it does now
My RFC targets 7.2 and 7.3 other than 7.4

6 years ago by Girgias — view source — reply

unread

I know this too. I am often in touch with Levi and void variance is not
covered by his RFC
As a matter of fact, if you try to compile that PR void will behave exactly
like it does now

First of all, apologies as I needed a brush up on the difference between
general variance and covariance.
In fact, the RFC linked does not cover the variance of the void type.

My RFC targets 7.2 and 7.3 other than 7.4

Secondly, I am nearly certain, but I would love to be proven wrong, that
new features aren't backported to older PHP releases.
So even then I don't think this will land in PHP 7.2/7.3

Now back to the proposal of the variance of void type.
I'm not sure I see the point of it?
Let me explain: if I define a method as void it means that it does stuff
which doesn't/can't return a sensible value.
Also, I am defining behavior and changing the return type, at least to me,
is a change in behavior.
Because a function/method which clearly is not intended to be used as a
value can now under your proposal become one.
Sure you can say that the return value may be only used by the child class
but if I want to change my parent class to this child class
I can't be sure that it will behave as before because maybe the child
class needs the return value of this previously void method.

Maybe I am just overthinking this however in my opinion if a return type
needs to be changed from void to something you are trying to
add behavior to a method which probably should go into its own method.

Best regards

George P. Banyard

6 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

Recent events convinced me to write this RFC :P

Please have a read here https://wiki.php.net/rfc/allow-void-variance

I am targeting all the supported PHP versions because this is mainly to
placate the discontent that arised by PHPUnit enforcing its users to use
void, so waiting 7.4 doesn't make much sense.

I was never a big fan of void pseudotype, but since it exists, I think
it makes sense to be able to override it. It does not violate the
protocol (since it's impossible in PHP for function to not return a
value, and it's very implausible anybody relies on void function to
return null). And since we have users complaining, it makes sense to fix it.

--
Stas Malyshev
smalyshev@gmail.com

6 years ago by Kalle Sommer Nielsen — view source — reply

unread

Hi Wes

Den man. 4. feb. 2019 kl. 05.19 skrev Wes netmo.php@gmail.com:

Hello PHPeeps!

Recent events convinced me to write this RFC :P

Please have a read here https://wiki.php.net/rfc/allow-void-variance

I am targeting all the supported PHP versions because this is mainly to
placate the discontent that arised by PHPUnit enforcing its users to use
void, so waiting 7.4 doesn't make much sense.

I don't like to suddenly change things like that in lower versions. I
would be for it for 7.4, but not merging to already active releases
branches. That is usually not how we deal with things like this.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

6 years ago by Rowan Collins — view source — reply

unread

Recent events convinced me to write this RFC :P

Please have a read here https://wiki.php.net/rfc/allow-void-variance

I was thinking about this this afternoon, and I think the current
behaviour is actually correct, and this constraint should stay invariant.

My reasoning is that ": void" isn't actually a type constraint - there
is no "void type" to apply the rules of covariance and contravariance
to. It's tempting to place it on a par with ": null", but a void
function evaluates to null only for the same reason an unset variable
does: because the runtime has to give you something.

Instead, ": void" in PHP represents a behavioural constraint on the
function - it declares that within this function, anything of the form
"return $value" is to be treated as an error. In other languages, the
same constraint might be enforced by declaring the routine as a
"procedure" rather than a "function".

As such, it is more appropriate to compare "void vs non-void" to "static
vs non-static", which is an invariant constraint - you can't over-ride a
static method with a non-static one, or vice versa.

(Incidentally, the RFC mentions TypeScript as precedent; there, "void"
apparently is a type, not just a keyword in function signatures:
https://www.typescriptlang.org/docs/handbook/basic-types.html)

Regards,

--
Rowan Collins
[IMSoP]

6 years ago by Michael Wallner — view source — reply

unread

I second Rowans thoughts.

Am So., 17. Feb. 2019, 17:36 hat Rowan Collins rowan.collins@gmail.com
geschrieben:

Recent events convinced me to write this RFC :P

Please have a read here https://wiki.php.net/rfc/allow-void-variance

I was thinking about this this afternoon, and I think the current
behaviour is actually correct, and this constraint should stay invariant.

My reasoning is that ": void" isn't actually a type constraint - there
is no "void type" to apply the rules of covariance and contravariance
to. It's tempting to place it on a par with ": null", but a void
function evaluates to null only for the same reason an unset variable
does: because the runtime has to give you something.

Instead, ": void" in PHP represents a behavioural constraint on the
function - it declares that within this function, anything of the form
"return $value" is to be treated as an error. In other languages, the
same constraint might be enforced by declaring the routine as a
"procedure" rather than a "function".

As such, it is more appropriate to compare "void vs non-void" to "static
vs non-static", which is an invariant constraint - you can't over-ride a
static method with a non-static one, or vice versa.

(Incidentally, the RFC mentions TypeScript as precedent; there, "void"
apparently is a type, not just a keyword in function signatures:
https://www.typescriptlang.org/docs/handbook/basic-types.html)

Regards,

--
Rowan Collins
[IMSoP]

6 years ago by php@braten.be — view source — reply

unread

Hi

I think this is a great idea, and that it should be implemented.

Instead, ": void" in PHP represents a behavioural constraint on the
function - it declares that within this function, anything of the form
"return $value" is to be treated as an error. In other languages, the
same constraint might be enforced by declaring the routine as a
"procedure" rather than a "function".

As such, it is more appropriate to compare "void vs non-void" to "static
vs non-static", which is an invariant constraint - you can't over-ride a
static method with a non-static one, or vice versa.

I think this is flawed reasoning.

Yes, you can view it as behavioral constraint on the current method, but
I do not think that alone is a valid reason to impose the same
constraint on all decendants of that class.

Yes, "static" is an invaraint constraint, but I think we should consider
this "void" constraint differently and not enforce that same invariance.

The reason is that is fits very well with the Liskov substitution
principle. Any decendant class can be subtituted safely in existing
code, even if the decendant should be trying to return something.

This also gives the least amount of surprise to a developer after RFC
https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
has been implemented. Then developers will expect that return values can
be different as long as the Liskov substitution principle holds.

Terje Bråten.