Implemented "Nullable Types"

[dstogov]

according to https://wiki.php.net/rfc/nullable_types

[allan-simon]

Hello, what is the status of RFC ? especially now that php7 will have an improved type checking, nullable type will be a significant improvement I think.

[dstogov]

Hi Levi,

This was your RFC, and I don't completely understand why we missed it.
In my opinion, this would be a really good addition.

Thanks. Dmitry.

On Mon, Apr 27, 2015 at 9:01 AM, Allan Simon notifications@github.com
wrote:

Hello, what is the status of RFC ? especially now that php7 will have an
improved type checking, nullable type will be a significant improvement I
think.

—
Reply to this email directly or view it on GitHub
#1045 (comment).

[staabm]

//cc @morrisonlevi (just making sure he gets notified)

[morrisonlevi]

The short answer is that ?Foo is short for Foo|null in multiple languages that I respect. It doesn't make sense to add the shortcut first and actual feature later. This also requires that null is allowed as a type, which would also enable the idea of a void return type: function foo(): null. This makes sense in PHP because functions will return null if you don't return anything.

[dstogov]

I see your point.
However, missing an ability to return NULL if type hint is specified, is a
real limitation.
Even C++ and Java code often do this.
Multiple type-hinting is a different feature.
And PHP users will have to live without it at least a year.

Thanks. Dmitry.

On Mon, Apr 27, 2015 at 5:24 PM, Levi Morrison notifications@github.com
wrote:

The short answer is that ?Foo is short for Foo|null in multiple languages
that I respect. It doesn't make sense to add the shortcut first and actual
feature later. This also requires that null is allowed as a type, which
would also enable the idea of a void return type: function foo(): null.
This makes sense in PHP because functions will return null if you don't
return anything.

—
Reply to this email directly or view it on GitHub
#1045 (comment).

[morrisonlevi]

The ability to type a parameter or return as Foo or null is multiple types. We even define null as a type in our manual:

NULL is the only possible value of type null.

I know waiting another year will pain some people, but they can make do like they have always done in years past and just omit the types or rely on documentation. There are plenty uses of return types without |null, which is why they were separate RFCs.

This also isn't a pressing issue since we're well past the 7.0 freeze. This means we have to wait until 7.1, so there is no hurry at all. I haven't forgotten about it :)

[Wes1262]

+1 for null|Baz @morrisonlevi

[alexstanciu-1]

Hi,

This is very important! For non scalar returns the return type feature of PHP7 is not usable.
Consider we are doing quite a lot of things like $company->getPreferredSupplier() or $company->queryPreferredSupplier(). I don't want an error just because an element is not there.
We have migrated our entire framework to PHP7, but I had to tell the team "no return types" as it may just push them in bad coding practices.
Return types is a good feature as it may throw exceptions earlier and avoid wasting time on debugging. Due to the nature of PHP it's not very useful for scalar types, the main benefit would have been for data types.
From an OO point of view NULL should along with any user defined type (especially when it's part of a model). A DB is full of NULLs and we do get them when we query.
Imo for any non-scalar it should have accepted NULL as a return by default. In C++ if you return a pointer to an object, you can also return NULL.

Regards

[samdark]

It's implemented like that in TypeScript. The only difference is that in TS ? is at the end which I think is much nicer:

function(a: string?) { ... }

[bobmagicii]

please oh god please lets get this cleaned up and commited. im seriously dying inside with every line i write that is not nullable.

[dstogov]

this may be solved only in PHP-7.1 (there is no release plan yet)

[crazytonyi]

Regarding the idea :

A default parameter and a nullable type are distinct and separate; you cannot use a default parameter where a nullable type existed in a parent; you cannot use a nullable type where a default parameter existed in a parent.

While allowing for a nullable type implies that no non-null default value can be set (since the default value would presumably always override a null value passed in), the inverse, I don't think, is true, eg that setting a default value of NULL excludes the ability to use a nullable type. Using your example:

function f(?callable $p) {}
f(); // invalid; function f does not have a default 

This makes sense, but shouldn't the following also be valid:

function f(?callable $p = NULL) {}
f(); // valid; function f has a default of NULL
f(null); // valid; function f allows nullable argument
function someFunction() {}
$functionVariable = 'someFunction';
f($functionVariable); // valid; function f allows callable argument

[raoulvdberge]

What is the state of this PR?

[morrisonlevi]

I am going to work more on this after mid-April when I have more time.

[nikic]

Superseded by #1893, which was merged.