Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82683
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
References: <680FB44D-B42D-4898-A28B-FA1C6E4D4D1A@ajf.me> <54DEE32B.6040706@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <54DEE32B.6040706@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <CA295D26-8BE0-46D4-8C09-C34CC26919F7@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Date: Sat, 14 Feb 2015 12:42:01 +0000
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Void Return Type
From: ajf@ajf.me (Andrea Faulds)

Hi,

> On 14 Feb 2015, at 05:54, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>=20
> Hi!
>=20
> I'm not sure what it is useful for, exactly. I mean, the more fatal
> errors the merrier, but I fail to see what exactly use except having yet
> more cases when your code may break it provides. I mean, if you defined
> a void function, that means you're not using it return value anywhere.
> Then who cares what return statement says?

What would be the point of *allowing* returning a value? It's clearly an err=
or. We could let you return anything and then discard it, but now you won't s=
pot the error in your code.

> Additionally, this RFC gets inheritance wrong - having return from
> function that previously did not return anything is not a violation of
> contract, since there's no practical contract that can rely on function
> not returning anything (in fact, there's no way in PHP to even check
> that AFAIK).

I am wondering about inheritance as well. I thought of void as having no sub=
class. But it's not really a return type for our purposes, it's more like a d=
eclaration that a function doesn't return anything.

So, I guess inheritance should allow removing or changing the typehint if it=
 is void. I might need more opinions on this first, though.

> Summarily, this seems to me an exercise in strictness for the sake of
> strictness. There are languages that force people to abide by a lot of
> rules because their creators believe more rules is the same as better
> code, but PHP never was one of them and the fact there are so many
> people trying to make PHP that makes me sad.

It's not merely for the sake of it. It makes function signatures more descri=
ptive, and lets you catch bugs in your code.

We already use void in the manual: why not in PHP?

--
Andrea Faulds
http://ajf.me/=