Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92318
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.75 as permitted sender)
User-Agent: Microsoft-MacOutlook/14.6.2.160219
Date: Thu, 14 Apr 2016 17:19:51 -0400
To: Levi Morrison <levim@php.net>
CC: php-internals <internals@lists.php.net>
Message-ID: <D3357498.6D41E%fsb@thefsb.org>
Thread-Topic: [PHP-DEV] [RFC] Nullable Return Type Declaration
References: <D33531D4.6D3F3%fsb@thefsb.org>
 <CAFMT4NqGa=mKUksczpe6HepjM1Wthsw9dY7dX3JBWO9xB-FLJA@mail.gmail.com>
In-Reply-To: <CAFMT4NqGa=mKUksczpe6HepjM1Wthsw9dY7dX3JBWO9xB-FLJA@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration
From: fsb@thefsb.org (Tom Worster)

On 4/14/16, 12:35 PM, "Levi Morrison" <morrison.levi@gmail.com on behalf
of levim@php.net> wrote:

>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?

I agree that `$node->setLeft()` is weird but I find `$node->setLeft(null)`
still a bit weird. Perhaps something like `$node->resetLeft()` would work?
Was that the idea?


>Additionally, on occasion I'll see functions like this:
>
>    function foo(Bar $b = null, $not_optional_param);

The only thing we can know for sure from this is that the programmer
urgently needs reeducation :)


>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.

Yes but still a code smell to me. I'd need to know more about the
programmer's intent for `foo(null, "value")`. It might be better to swap
order, or change the method name, or add another method... Who knows? Need
to take each case individually.

This kind of asking questions about intent in code review is good for code
quality. That's why I like how PHP doesn't allow this. It encourages the
question asking. Every case is different, of course, so you can surely
find counter examples. But on balance I'd say it's better to disallow it.


Does this help you understand my preference? I think the restriction
encourages a healthy discipline.

Otoh, I think nullable return is a pressing need.

Tom