Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110829
MIME-Version: 1.0
References: <CANeKSiRe95yUeyUV5S3MU1Bzh7A_Z0OQF_WVNFK16CcbE5wYqw@mail.gmail.com>
 <CAOWwgpnb88sZL8GfaFvdkcFL+5rwJntOoRVUxZD1Hu8xiShxRQ@mail.gmail.com>
In-Reply-To: <CAOWwgpnb88sZL8GfaFvdkcFL+5rwJntOoRVUxZD1Hu8xiShxRQ@mail.gmail.com>
Date: Fri, 3 Jul 2020 12:08:44 +0300
Message-ID: <CANeKSiQo8-AqafnctP422HHqKqLGqG5n4UL-K+vOvfZY2v4BcQ@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fac74905a985df0f"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000fac74905a985df0f
Content-Type: text/plain; charset="UTF-8"

Hey Nicolas,

Hey internals,
>>
>> I have opened the voting for the RFC, let's hope everything is going
>> to be smooth :). If you have any other questions, let me know!
>>
>> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
>>
>
> Hi Benas,
>
> I voted "no" to the RFC because to me adding "void" to constructor and
> destructor don't add any value: the semantics of these functions are
> totally defined. Annotating the code with "void" is duplicate information.
>

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().

> Adding `: string` to that method provides exactly zero additional
information.  You know it's going to return a string. That's it's whole
purpose.  On the off chance someone is returning a non-string right now,
they're very clearly Doing It Wrong(tm).  However, the stringable RFC added
the ability to put `: string` on the method in order to be clearer, more
explicit, and to not annoy type fans who are like "Ah, I've typed every one
of my methods... except this one, because I can't, raaaah!"

> I see this as the same for constructors.  Any constructor returning
non-void right now is Doing It Wrong(tm), and you know that going in.  But
being able to make the obvious explicit still has its advantages, both for
documentation and for consistency.

Rowan:
> As long as it's possible to return things from constructors, then it is
> "obvious" that a given constructor is void only in the same way that it
> is "obvious" that a method called "convertToArray" returns an array. I
> would be surprised if any style guide would forbid writing "public
> function convertToArray(): array", so would be equally surprised to see
> one forbid writing "public function __construct(): void". In both cases,
> the extra marker takes the reader from 99% certain to 100%.

Another thing to consider is that the explicit `: void` declaration causes
the check to be enforced in PHP 8.0. Meanwhile, the implicit check will
only be done in PHP 8.1/9.0 (depending on the secondary vote).

best this can do is open another code-style bikeshed war. About forbidding
> the functions from returning anything, I don't understand why this would
> improve the overall quality of anything. To me, this looks like gratuitous
> strictness.
>

Quite honestly, every feature/change in PHP results in some kind of a
code-style war. It is not possible to be "politically" neutral.

Moreover, allowing `__clone` (as of "Ensure correct magic methods'
signature" RFC) to have an explicit `void` return type but disallowing that
for constructors/destructors doesn't make much sense. In fact, that is more
likely going to create a code style war since not allowing ctors/dtors to
have an explicit type would be inconsistent.

`__construct` and `__clone` work in a similar fashion yet `__clone` can
have an explicit `void` return type and `__construct` - does not.

I also don't understand the secondary vote: enforcing "void rules" in 8.1
> is a not-allowed BC break. This can only target 9.0 to me, there can be no
> discussion about it in a specific RFC. Or did I miss something?
>

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 raised that question in the original thread but didn't get any replies on
that matter. Thus, I have put this as a secondary vote.

This is just my opinion on the matter of course. Thanks for contributing to
> PHP.
>

...and a highly appreciated one, thanks!

Nicolas
>

Best regards,
Benas Seliuginas

>

--000000000000fac74905a985df0f--