Re: [RFC] Nullable Return Type Declaration

From: Date: Thu, 14 Apr 2016 16:35:44 +0000
Subject: Re: [RFC] Nullable Return Type Declaration
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-92305@lists.php.net to get a copy of this message
On Thu, Apr 14, 2016 at 9:39 AM, Tom Worster <fsb@thefsb.org> wrote: > I would like to introduce for discussion an RFC proposing and arguing for > Nullable Return Type Declaration in 7.1 and deferring for now more general > relaxations of 7.0 type as proposed in Levi's two RFCs. > > https://wiki.php.net/rfc/nullable_returns > > If anyone would like to collaborate on the RFC, I have a repo you may fork: > https://gist.github.com/tom--/e95a10fbe4d34f8a72c9 (although > guthub's > formatting isn't lovely). I'm looking for help with implementation. > > Tom > > > I can appreciate that you want only the restricted union with null. However, I do not see the point of disallowing it for parameter types while allowing it for return types: function setLeft(Node $n = null) { $this->left = $n; $this->updateHeight(); } Why disallow the explicit union with null here instead of the default parameter which does not exactly capture the desired semantics? Calling $node->setLeft() is just odd, almost as if it was a mistake. I would much prefer $node->setLeft(null) here. Basically, if we have a feature for return types that exactly matches the semantics that we occasionally want for the parameter types why forbid it? Additionally, on occasion I'll see functions like this: function foo(Bar $b = null, $not_optional_param); Why not allow nullable types on parameters to avoid that wonkiness caused by default values of null? function foo(Bar | Null $b, $not_optional_param); This is much better.

« previous php.internals (#92305) next »