Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92338
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.65 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <57110DC5.8000007@garfieldtech.com>
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>
	<CAFMT4NpOCf3VON01_3n4xMKVOhEVNL-CsRm5gYOgogEnwt=XvQ@mail.gmail.com>
	<5710BA79.5060108@lsces.co.uk>
	<57110DC5.8000007@garfieldtech.com>
Date: Fri, 15 Apr 2016 10:10:37 -0600
Message-ID: <CAFMT4No5DPikRwbMmid+iMNeP3i+FfEhCEp775=aaChTFUM-SQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: 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)

> I'm not suggesting that we purge NULL from the language.  That's
> impractical/impossible. I'm suggesting we shouldn't soften the type system
> added in 7.0, which discourages its use in most cases, as it should be.

It is a common misconception I've heard several times now that union
types is weakening or softening the type system. I want to reiterate
that it is already possible to use multiple types. It is already done
in the wild. It is done all over our standard library. The union types
RFC just allows you to encode the specific types to be passed or
returned. In other words it is aiming to make using the dynamic types
of PHP safer by allowing you to explicitly write out the options.

The Nullable Return Types RFC is basically arguing that the only
useful union of types is `T | Null` and only for return types. I've
already stated a few of my concerns with that belief and have not been
convinced by the rebuttles to change my mind.

Also, to specifically address a concern Larry had earlier about
nullable types in general:

> I am highly, highly sceptical about nullable parameters or returns, and frankly would rather they were not included in the language.

Just to clarify: we already have nullable parameters because of a
default of null. It's already in the language and people have asked
many times for this functionality to be expanded to include return
types. I should have kept a master list every time someone contacted
me on github, email, twitter, etc about this so I could easily list
them all as references in the relevant RFCs for demand for the
feature.