Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110831
MIME-Version: 1.0
References: <CANeKSiRe95yUeyUV5S3MU1Bzh7A_Z0OQF_WVNFK16CcbE5wYqw@mail.gmail.com>
 <CAOWwgpnb88sZL8GfaFvdkcFL+5rwJntOoRVUxZD1Hu8xiShxRQ@mail.gmail.com> <CANeKSiQo8-AqafnctP422HHqKqLGqG5n4UL-K+vOvfZY2v4BcQ@mail.gmail.com>
In-Reply-To: <CANeKSiQo8-AqafnctP422HHqKqLGqG5n4UL-K+vOvfZY2v4BcQ@mail.gmail.com>
Date: Fri, 3 Jul 2020 11:49:21 +0200
Message-ID: <CAOWwgpkMxq60CygHKPT+Zi-M3tPcFroYj+ASij+_B3GcHYWZxw@mail.gmail.com>
To: Benas IML <benas.molis.iml@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000028941205a98671fc"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000028941205a98671fc
Content-Type: text/plain; charset="UTF-8"

I think that Larry's and Rowan's replies on the original discussion thread
> really well explained as to why it makes sense to allow an explicit `void`
> return type, so I'll just quote them instead ;)
>
> Larry:
> > I see this in the same category as __toString().
>

I read those yes, but there are subtle yet critical differences to me:

in PHP < 8, 1. the return-type of __toString is already enforced by the
engine (just not by the type-system, but the end result is the same) and 2.
it is already allowed to add the "string" return type to the method.

for constructors/destructors, neither 1. nor 2. are true: they *do*not*
allow any return type and they don't check the return value.

This means that the change on __toString is mostly transparent (only the
exact error message is different), while the proposed change is not. It
will have a cost for the community, and my opinion is that this cost is not
worth it.

> Any constructor returning non-void right now is Doing It Wrong(tm)
>

That's precisely what I read as "gratuitous strictness" (no offense to
anyone, I respect this opinion.)
Especially when this might become "enforced".



> Since some internals told me that PHP doesn't follow semver strictly, it
> would make sense to enforce the check in PHP 8.1 already.
>

I invite you to read https://wiki.php.net/rfc/releaseprocess where this is
detailed.
Here is the relevant excerpt: "x.y.z to x.y+1.z" => "Backward compatibility
must be kept".

A dedicated vote in a specific RFC cannot overrule this policy AFAIK.

Thanks for your answer,
Nicolas

>

--00000000000028941205a98671fc--