Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110833
MIME-Version: 1.0
References: <CANeKSiRe95yUeyUV5S3MU1Bzh7A_Z0OQF_WVNFK16CcbE5wYqw@mail.gmail.com>
 <CAOWwgpnb88sZL8GfaFvdkcFL+5rwJntOoRVUxZD1Hu8xiShxRQ@mail.gmail.com>
 <CANeKSiQo8-AqafnctP422HHqKqLGqG5n4UL-K+vOvfZY2v4BcQ@mail.gmail.com> <CAOWwgpkMxq60CygHKPT+Zi-M3tPcFroYj+ASij+_B3GcHYWZxw@mail.gmail.com>
In-Reply-To: <CAOWwgpkMxq60CygHKPT+Zi-M3tPcFroYj+ASij+_B3GcHYWZxw@mail.gmail.com>
Date: Fri, 3 Jul 2020 13:42:52 +0300
Message-ID: <CANeKSiR7=n7U2iHTNwCSa7B2ogLovM0Y8gfT+OyQVRzjWKLwTQ@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000092cbf305a9873072"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
From: benas.molis.iml@gmail.com (Benas IML)

--00000000000092cbf305a9873072
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.
>

Well, for `__clone` neither 1 nor 2 are true as well. But as of PHP 8.0 it
will be allowed to declare an explicit `void` return type on `__clone`.
Thus, this will have a higher cost for the community since this behavior
will be quite inconsistent with constructors/destructors which do not allow
to declare an explicit return type.


> > 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".
>

That is rather subjective.

Adding an explicit `void` return type allows to clearly show developer's
intention to not return values from a constructor/destructor. While some
people might not see any value in this, I personally do (and many others
too).

Moreover, as mentioned before, adding an explicit `void` return type causes
the check to already be done in PHP 8.0. Which otherwise implicitly will
only be done in PHP 8.1/9.0.


>
>
>> 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.
>

See Nikita's reply.

But if more internals find this controversial, I can close the secondary
vote, that's okay with me.


> Thanks for your answer,
> Nicolas
>

Best regards,
Benas

>

--00000000000092cbf305a9873072--