Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82704
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'Andrea Faulds'" <ajf@ajf.me>
Cc: "'PHP Internals'" <internals@lists.php.net>
References: <680FB44D-B42D-4898-A28B-FA1C6E4D4D1A@ajf.me> <006701d0489c$86a12470$93e36d50$@tutteli.ch> <DDE35D59-4CC8-4B78-8D12-47E6063B0BF1@ajf.me>
In-Reply-To: <DDE35D59-4CC8-4B78-8D12-47E6063B0BF1@ajf.me>
Date: Sat, 14 Feb 2015 23:30:47 +0100
Message-ID: <006801d048a5$e14a96f0$a3dfc4d0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJarA5HcqMrZRaN+23HbEjTjl9TGQIGb4poAYEkhhebv6xswA==
Content-Language: de-ch
Subject: AW: [PHP-DEV] [RFC] Void Return Type
From: php@tutteli.ch ("Robert Stoll")

> -----Urspr=C3=BCngliche Nachricht-----
> Von: Andrea Faulds [mailto:ajf@ajf.me]
> Gesendet: Samstag, 14. Februar 2015 22:38
> An: Robert Stoll
> Cc: PHP Internals
> Betreff: Re: [PHP-DEV] [RFC] Void Return Type
>=20
> Hi Robert,
>=20
> > On 14 Feb 2015, at 21:23, Robert Stoll <php@tutteli.ch> wrote:
> >
> > I think a void type for PHP would make sense but only if the return =
value of such a function cannot be used.
>=20
> Why?=20

I already mentioned why, because it is inconsistent. I see that you look =
at it from another point of view. Maybe I missed something but I figured =
the following function:

function foo(){}

is equivalent to=20

function foo() {return;}

is equivalent to=20

function foo() {return null;}

or am I wrong? Does it have a different behaviour?

If not, then still claim it is inconsistent. NULL is treated as own type =
in PHP (at least specs says so [1]) hence I do not see why null should =
be returned when the function is defined as void (but I would also be =
happy with the other suggestions below)
=20
[1] =
https://github.com/php/php-langspec/blob/0f9985ba76ab7890a9a8440f8a4344c5=
8f0a6761/spec/05-types.md#the-null-type

> If the return value cannot be used, it prevents the function being =
used with any API that stores the return value of a callback. =
That=E2=80=99s not terribly nice.

No problem to wrap such a function into another callback returning null. =
It was not defined with void for no reason, that is how I look at it.

>=20
> A void return value doesn=E2=80=99t need to enforce anything on the =
caller. PHP has always filled in missing values with NULLs,
> including return values, like other dynamic languages do here.

In what other cases does PHP fill in missing values with NULLs (expect =
from return type and collection initialisation, that is something =
different IMO)?


>=20
> > Otherwise it is another reason for people to laugh at PHP and =
justifiably so, telling that a function does not return
> anything but return null is very inconsistent.
>=20
> It does implicitly return NULL, but NULL is a useless value, and =
it=E2=80=99s returned implicitly, rather than explicitly. I =
don=E2=80=99t think it=E2=80=99s
> really that ludicrous.

How dare you calling NULL useless :P=20

Might be that other do not think it is inconsistent. For me it does not =
make a difference if something is returned explicitly or implicitly, in =
the end it still returns something and this something needs to be of the =
type the return type hint claims to be. That is what I define =
consistent.
I could live with the idea of void as alias for null (or abstract parent =
type of null if you do not like an alias) but otherwise, why should the =
following not be allowed:

function foo : void { return null;}

when it is returned anyway if I omit the statement?

>=20
> > I suggest to use one of the following behaviours:
> > 1. declaring a function void does not return anything (hence is like
> > echo to a certain agree)
>=20
> That makes it cease to be a function in the PHP sense. PHP always =
allows functions to be used in expressions.

Sure, every function which returns something (explicitly or implicitly) =
can be used in an expression. If void defines to return nothing, then it =
could not be used in an expression. I do not see a problem here, no =
rather the other way round. Consider the following example:

function foo() : void {}
$b =3D foo() + 1; //I would like to see an error here rather that 1 is =
assigned to $b

>=20
> > 2. declaring a function void does return a thing of type void (that
> > would be similar to Unit in scala)
>=20
> We don=E2=80=99t need another form of NULL.
>=20
> Also, a thing of type void could be passed around, just as the unit =
type can be in other languages, so it wouldn=E2=80=99t do what
> you want it to.

Of course it would. void could be defined in such a way that it does not =
support implicit conversions to other types. Taking the example from =
above the following would result in an error as well:

function foo() : void {}
$b =3D foo() + 1; //would emit an error "Unsupported operand types for =
+" like it is done for: new Exception() + 1;

And as someone else on the list already mentioned such an approach would =
allow other features.

>=20
> > 3. instead of void a function can be declared to be of type null ->
> > almost the same behaviour as your RFC but without the inconsistency
>=20
> That seems like a strange solution. You=E2=80=99re requiring the =
function to always return a useless value.

Yes, that is what already happens anyway. You look at it from the wrong =
point of view IMO, you did not consider the implicit return to be =
similar to implicit conversions respectively.  A user would not be =
required to write a return statement like a user is not required to cast =
an int value to string when passed to an internal function which expects =
string. If you think in this terms then it makes absolutely sense to =
state that a function returns null.

>=20
> --
> Andrea Faulds
> http://ajf.me/
>=20
>=20
>=20
>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, =
visit: http://www.php.net/unsub.php