[RFC][Discuss] Covariant return- and contravariant parameter- types

5 years ago by Marcos Passos — view source

unread

I'm waiting for it for a long time! Thank you for putting effort on this!

Em seg, 26 de nov de 2018 às 19:26, Levi Morrison levim@php.net escreveu:

5 years ago by michal@brzuchalski.com — view source

unread

Can't wait for it to happen!
Thank you for your work and fixing object type.

pon., 26 lis 2018 o 22:26 Levi Morrison levim@php.net napisał(a):

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

5 years ago by Benjamin Morel — view source

unread

I can only say that I've been waiting for this feature for years and am
really looking forward to see it implemented, hopefully in 7.4.
Good job on the RFC, I wish you luck!

5 years ago by Larry Garfield — view source

unread

Looks like fun!

Would this also include allowing a return type of static, which would be
useful for the "Return the object that was invoked" case or "return a new
instance of the same object" case? Currently we're limited to return self,
which is, of course, not the same thing and less flexible.

--Larry Garfield

5 years ago by Levi Morrison — view source

unread

It does not. To be honest, I did not think of it until your question.

5 years ago by Marcos Passos — view source

unread

Supporting static return would come in handy to define interfaces for
immutable objects.

Em ter, 27 de nov de 2018 às 19:01, Levi Morrison levim@php.net escreveu:

5 years ago by Levi Morrison — view source

unread

After thinking about it, I believe it is out of scope for this RFC.
While static would be covariant, it's also more than that.
Accordingly, it deserves to have its own consideration and voting.

5 years ago by Larry Garfield — view source

unread

Exactly the sort of use case I was thinking of. Or for builder objects, where
you mutate the object in place and then return it. That's a common pattern,
but return self and subclasses don't play that nicely there.

Levi, is that something that could be reasonably added to this RFC or is that
Hard(tm), like scalar/callable/etc?

(I don't know that a static/self parameter declaration is even a thing, so it
probably doesn't matter there; it does matter for returns, though.)

--Larry Garfield

5 years ago by Dan Ackroyd — view source

unread

Marcos Passos wrote:

But it's not a requirement, right? With this RFC, the following code will work:

class ParentImmutable
{
function modify() : ParentImmutable
{
...
}
}

class ChidImmutable extends ParentImmutable
{
function modify() : ChidImmutable
{
...
}
}

Why should the RFC be expanded in scope to enforcing that child
classes use more specific types?

Currently, static, self and parent are really more syntactic sugar
that only apply in specific contexts, rather than actual types. This
is a great source of sadness when it comes to their use in 'callable':
https://wiki.php.net/rfc/consistent_callables . If I (or some other
brave soul) finds enough fortitude to pickup that RFC, their use in
the language might decrease.

But more importantly, expanding the RFC from 'allowing variance to
happen' to 'enforcing that child classes use variance' seems quite a
big step, and would really need a separate strong rational of why it
is needed, and why the added complexity is a good trade-off when it
doesn't seem to be required for the use-case that it is being
suggested for.

It definitely needs a stronger argument for it, other than just saying
it would be possible.

cheers
Dan
Ack

5 years ago by Levi Morrison — view source

unread

Our existing engine doesn't always resolve "parent" at compile time
when possible. As part of this patch "parent" is resolved at
compile-time when possible and warnings and/or errors are emitted in
certain cases where there were none before. For instance, this would
only cause an error only if the method C::m were to be used:

&lt;?php
class C {
  static function m(parent $m) {}
}
?>

This now emits an E_DEPRECATED warning when C is compiled. In 8.0 this
should be elevated to a COMPILE_ERROR.

The current edition of the RFC fails to mention this.

5 years ago by Levi Morrison — view source

unread

It has been two weeks now. If you want to provide any feedback, or
follow-up on anything from the discussion, please do so soon. I hope
to put this to vote before the end of the year.

5 years ago by Christoph M. Becker — view source

unread

Thanks for working on this, Levi. Highly appreciated!

I may have missed this, but otherwise I'd be quite surprised that nobody
had commented on:

| Therefore, by-reference parameters are still contravariant, […]

Call-by-reference is not seldom used to provide out-parameters, but
these should not be contravariant according to LSP. Therefore, it might
be best to keep by-reference parameters invariant.

--
Christoph M. Becker

5 years ago by Levi Morrison — view source

unread

Christoph, we cannot make any guarantees about the type of the
variable when the function returns because the type of the parameter
is only checked on function entry, and not also on function exit, e.g.

function array_baz(array &$in) {
  $in = 1;
}
$array = [];
array_baz($array); // valid
var_export($array); // 1

I do think we ought to have "out" parameters some day which would
prevent this behavior (as well as have some other benefits), but that
is out of scope for this RFC. The RFC notes that if we had "inout"
parameters that they would need to be invariant. It also says that
"out" parameters would be invariant, but they may be covariant
depending on the exact semantics specified -- all that can be handled
in the RFC that proposes it.

I will add this example (or maybe a better one) to the RFC. Thanks for
bringing it up.

5 years ago by Christoph M. Becker — view source

unread

I was not aware of this – thanks for the explanation. In my opinion,
yet another good reason to avoid references.

Thanks. Also documented now:
http://svn.php.net/viewvc?view=revision&revision=346309.

--
Christoph M. Becker

[RFC][Discuss] Covariant return- and contravariant parameter- types

-- regards / pozdrawiam,

--
regards / pozdrawiam,