Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92320
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.196 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <D3357498.6D41E%fsb@thefsb.org>
References: <D33531D4.6D3F3%fsb@thefsb.org>
	<CAFMT4NqGa=mKUksczpe6HepjM1Wthsw9dY7dX3JBWO9xB-FLJA@mail.gmail.com>
	<D3357498.6D41E%fsb@thefsb.org>
Date: Thu, 14 Apr 2016 15:46:56 -0600
Message-ID: <CAFMT4NrN=q1ZBUXGBPquFTVVaJpoHfbhTDKU2LMZY1C5tu4FKg@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: php-internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration
From: levim@php.net (Levi Morrison)

>>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.

Having a separate method instead of `foo(null, "value")` makes it
difficult to use for the result of a function. Assume `bar()` returns
`Bar | Null`; this would no longer work if they were separated:

    foo(bar(), "value")

Functions are often composed so if something is the output of one
function it will likely be the input to another. Thus if returning
optionally null values is important to you so should optionally null
parameters.