Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92342
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.83 as permitted sender)
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
References: <D33531D4.6D3F3%fsb@thefsb.org>
 <CAFMT4NqGa=mKUksczpe6HepjM1Wthsw9dY7dX3JBWO9xB-FLJA@mail.gmail.com>
 <D3357498.6D41E%fsb@thefsb.org>
 <CAFMT4NrN=q1ZBUXGBPquFTVVaJpoHfbhTDKU2LMZY1C5tu4FKg@mail.gmail.com>
 <D335A5AA.6D579%fsb@thefsb.org> <57103A46.6040803@garfieldtech.com>
Message-ID: <57111DFA.6090006@thefsb.org>
Date: Fri, 15 Apr 2016 12:59:38 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <57103A46.6040803@garfieldtech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration
From: fsb@thefsb.org (Tom Worster)

On 4/14/16 8:48 PM, Larry Garfield wrote:

> I am highly, highly sceptical about nullable parameters or returns, and
> frankly would rather they were not included in the language.  By nature
> they undermine type safety.  At best, they indicate to all callers
> "*every* time you call this function, you MUST put is_null() around it
> or your program may fail randomly."

Yes.


> While that's better to know
> explicitly than not (which is the case for any untyped return, aka any
> PHP code pre-7.0), it would be better still to, well, not have to worry
> about that billion dollar mistake[1] cropping up in my code.

I agree.

To be clear, I do not intend the RFC to encourage nullable return or 
suggest that it's a fine thing to use. But given where we are, it's hard 
to imagine how to extirpate it.

When we started using PHP 7.0 type, initially when authoring new models 
(and using Yii2), it immediately became clear that we lacked two things: 
this and void returns. We're getting the latter in 7.1. It would be very 
nice if we could have both.

I'm a practical PHP user, with a generally conservative attitude to the 
language, often unmoved by proposals add a feature because some other 
more fashionable language has it (I call it language envy, to borrow 
from Freud). And while PHP 7.0 is good, I'd rather have Something|null 
in the return declaration than just in the docblock. That's all.


> In a sense, if we really must allow for value-or-null (which I consider
> a code smell in the 98% case) I'd prefer if it was ONLY available via
> union types: That is, Something|null.  That's longer and clumsier to
> type, and harder to read.  Which it should be. (Static casts in C++ have
> a fugly syntax, which has been defended by the language designers on the
> grounds that static casts are fugly, so the syntax for them should be as
> well to remind you to stop doing it. There is a fair amount of validity
> to that argument on affordance grounds, at least within C++.)  Using an
> easy short hand notation for something that is inherently a code smell
> when you're already typing your code only serves to encourage something
> we should be training people out of in the first place.

With regard to syntax, I prefer the long form `Something|null`. That 
seems very clear to me. The proposed short-hand ? syntax always makes me 
think of what I hate most about regex.

Tom