Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82681
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender)
References: <680FB44D-B42D-4898-A28B-FA1C6E4D4D1A@ajf.me> <012c01d04812$bf8e7560$3eab6020$@php.net>
Mime-Version: 1.0 (1.0)
In-Reply-To: <012c01d04812$bf8e7560$3eab6020$@php.net>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <0E369BA2-363A-4AF5-88F2-3643CCE55E5C@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Date: Sat, 14 Feb 2015 12:26:08 +0000
To: "<francois@php.net>" <francois@php.net>
Subject: Re: [PHP-DEV] [RFC] Void Return Type
From: ajf@ajf.me (Andrea Faulds)

Hey Fran=C3=A7ois,

On 14 Feb 2015, at 04:57, Fran=C3=A7ois Laupretre <francois@php.net> wrote:

> That's a nice addition and a beginning to distinguish void from null, as I=
 imagine the function still returns null.
>=20
> Now, what about making void a real zval type ? It would open a lot of poss=
ibilities. Unlike null, conversions from void would raise an error. It would=
 also be rejected as argument input type but could be used as an output type=
 when arg is passed by ref, it could be the default type for return_value (h=
uge BC break here) and so on...

We could do this, but for the longest time we've made all functions have som=
e return value, even ones which don't explicitly return one (they return NUL=
L). I think it'd be better not to change this. I expect IDEs and such could e=
arn you about it, though.

> There's a need for a real 'no value' type different from null, as null has=
 too many uses. If defined correctly, it can be a powerful addition.

If I was to go back to 1994, I'd add "undefined" to PHP like JS has. Today, t=
hough, I think that is unrealistic, as much as I wish it wasn't. A void type=
 only really makes sense as a pseudo-type for return type checking purposes,=
 IMO.


Thanks.=