Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54DF5B79.6050009@gmail.com>
References: <680FB44D-B42D-4898-A28B-FA1C6E4D4D1A@ajf.me>
	<54DEE32B.6040706@gmail.com>
	<CA295D26-8BE0-46D4-8C09-C34CC26919F7@ajf.me>
	<54DF5B79.6050009@gmail.com>
Date: Sat, 14 Feb 2015 15:52:18 +0100
Message-ID: <CAF+90c-EbdfavmZyL3L5xaY_MKe01rY4FGGQ+bKb4M0fhv+4mg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb04ee4e6e707050f0d7f86
Subject: Re: [PHP-DEV] [RFC] Void Return Type
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bb04ee4e6e707050f0d7f86
Content-Type: text/plain; charset=UTF-8

On Sat, Feb 14, 2015 at 3:28 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > What would be the point of *allowing* returning a value? It's clearly
>
> It's an error only because you declared it an error.
>
> > an error. We could let you return anything and then discard it, but
> > now you won't spot the error in your code.
>
> Function return values which are going unused all the time. In PHP,
> functions are very frequently called for side effects and not return
> values. So returning value and discarding it is a common and perfectly
> valid scenario. And it also has absolutely nothing to do with void
> declaration - void declaration doesn't cause discarding the value and
> you can discard the value with or without it.
>
> > It's not merely for the sake of it. It makes function signatures more
> > descriptive, and lets you catch bugs in your code.
>
> Only bug it can catch is wrongly declaring the function to be void -
> which is introduced by this RFC. For me, it is a clear case of
> generating error for the sake of error.
>
> > We already use void in the manual: why not in PHP?
>
> Because the manual is the *documentation*, not code. It explains that
> the function does not return anything useful. It's not the same as
> creating an error when function returns something useful.
>

One of the primary purposes of having typehints *is* documentation. This
applies both to our existing type annotations, to the newly introduced
return declarations - and to the void return type. The advantage of having
the type declaration be part of the language (rather than a docblock) is
brevity on one hand and verification of its correctness on the other hand.
It's easy to forget to update docblock type annotations, but you can't get
away with specifying an incorrect language-supported annotations - if you
use a wrong type annotation your code just won't work.

The void return type is actually the one case where we can at compile-time
fully verify that it is used correctly - which is great.

Allowing to return a value from a void function doesn't make sense. If you
want to return a value, don't declare it as void. If you declare it as
void, don't return a value. It's really as simple as that.

Nikita

--047d7bb04ee4e6e707050f0d7f86--