On 4/14/2016 6:35 PM, Levi Morrison wrote: > On Thu, Apr 14, 2016 at 9:39 AM, Tom Worster <f...@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. >
My guess is that this RFC only wants to get it for return because it might be an easier vote? I do not like the fact that only the long version of union types is supported and prefer the question mark approach as a short hand. Can this RFC be either extended to include that as well or removed so it does not get in the way of the other two RFCs? -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature