Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82688
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 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 07:01:21 -0800
Message-ID: <CAEZPtU6y6hY-NXxs_5ajNgQPd43V+3BROQjBRVtNqrNET4q8UQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Andrea Faulds <ajf@ajf.me>
Content-Type: multipart/alternative; boundary=001a113529824605f5050f0da093
Subject: Re: [PHP-DEV] [RFC] Void Return Type
From: pierre.php@gmail.com (Pierre Joye)

--001a113529824605f5050f0da093
Content-Type: text/plain; charset=UTF-8

On Feb 14, 2015 6:28 AM, "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.

I have no strong opinion on the void but reading this exact comment makes
me think that there is clearly an issue here.

How ignoring values is a perfectly valid scenario? Yes, there are cases
where some code does not need it but it is clearly not clean nor correct.

> > 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.

No. It makes clear about what happens and what should be expected. I see it
as a complement to the return type rfc.

> > 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.

I did not check the implementation yet but I suppose it does not default to
void, f.e. for existing codes. So I do not see about which "errors" you are
talking about here.

However yes, future codes (lib, apps, etc) using void will create this
error and it will be pretty easy to make the caller happy, no?

A common thing I see lately is to look at legacy code to consider what
should or can be php tomorrow. I consider it as a strategic mistake. I am
not saying we should drastically change php or force users to rely on new
paradigms. But we must provide features to make php relevant for a wider
audience. And it is possible to do it without making it less easy to use.
We had the same discussion about OO when we developed 5.0, see where we are
now. Stronger than ever.

Cheers,
Pierre

--001a113529824605f5050f0da093--