Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83067
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Michael Wallner'" <mike@php.net>,
	"'Sara Golemon'" <pollita@php.net>,
	"'PHP internals'" <internals@lists.php.net>
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com> <54E47546.5030800@php.net>
In-Reply-To: <54E47546.5030800@php.net>
Date: Wed, 18 Feb 2015 15:01:11 +0100
Message-ID: <031001d04b83$5a12b9c0$0e382d40$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgJdYzxomxw9CSA=
Content-Language: fr
Subject: RE: [PHP-DEV] Scalar Type Hints v0.4
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

Hi Michael,

The case of null is a little special.

As a type hint, we need it for return and union types only.

Considering union types, they were clearly left out of scope for 7.0 and =
I personally won't propose pre-defined union types before the general =
case for unions is designed. Conversion to union type, in particular, is =
complex, and requires more thinking and discussion.=20

> Hold on, usually, type checking functions don't identify NULL as =
scalar.

I don't understand your point as parameter parsing currently accepts =
null as scalar (converting to 0 or empty string).

If you mean is_xxx() functions, that's irrelevant because these =
functions, except a few ones like is_numeric(), are just based on zval =
type and don't accept *any* conversion.

I profit of this mail to propose :

- disabling accepting null as number, string, or bool (it is already =
rejected for other types).
- also disabling implicit conversions of any type to null (a function =
declared to return int couldn't return null without adding 'null' to its =
return type, which requires union types).

A consequence is that, until we have union types, a function returning =
int or null, for instance, cannot have an explicit type.

It is important because disabling implicit conversion to null allows to =
trap functions ending without an explicit 'return' statement, while =
supposed to return a value.

Example:

Function foo(int $a): int
{
If ($a > 0) return $a;
} <- Error : received null while expecting int

While this will be OK when union types exist :

Function foo(int $a): int|null
{
If ($a > 0) return $a;
}

Regards

Fran=C3=A7ois