Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109657
MIME-Version: 1.0
References: <CAP=4hC+9duSVcREvwOD3jZv+5fmqQzzR=UEraw4Yr6P+b+FfaQ@mail.gmail.com>
 <90F4B395-F010-4196-9C40-7896D4F3F2F4@gmail.com> <CAP=4hC+moKGF-XyGuaYEzc54tJb++5bUxCpF-8vXxsPS+NHuUw@mail.gmail.com>
 <CAP=4hCLH9PrkQxuF=m154jA2+d56eTXTfmtsCfjxOcBiR4pmsw@mail.gmail.com>
 <CAP=4hCLLY5THWuR1h-hiTQ4sW0Nb1Wv1+EYcSBhmaTYU6x7MOg@mail.gmail.com>
 <CAOWwgpmXfzDw4yWUEme_DtuiMitZf6vqYVm57F_nxYAAHPyORA@mail.gmail.com>
 <CAP=4hC+cxqXp-TLUUeRWg0q5=Bzi5dXMr_N7ypfVjTywP6zF1Q@mail.gmail.com>
 <CAOWwgpmK8Zzk4+LAnSFW0nTCR8qEaFG4AD_97zoDqvA7wh6kyA@mail.gmail.com>
 <0A374409-6FA6-4E02-A7E6-EACA3E42451C@gmail.com> <CAF+90c8wKkaT_2NdeHB0VOUmBnAEfaKsBDbaOEa1s8Z_arPyPA@mail.gmail.com>
 <436FD800-A316-4C99-8793-C6EF4BD15BE3@gmail.com> <CAF+90c8uO2KcO8t=syX+4GMMda62K6gsfpW+FCC22VVNLv+_Jw@mail.gmail.com>
In-Reply-To: <CAF+90c8uO2KcO8t=syX+4GMMda62K6gsfpW+FCC22VVNLv+_Jw@mail.gmail.com>
Date: Wed, 15 Apr 2020 16:50:50 +0200
Message-ID: <CAP=4hCLhiFyiDsqyDM=opzvvMOsf5OHFc68NBw_VCUB+GdPMFA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Claude Pache <claude.pache@gmail.com>, Nicolas Grekas <nicolas.grekas+php@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dcf31305a3557161"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Ensure correct magic methods'
 signatures when typed
From: carusogabriel34@gmail.com (Gabriel Caruso)

--000000000000dcf31305a3557161
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 15 Apr 2020 at 12:57, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Apr 14, 2020 at 7:45 PM Claude Pache <claude.pache@gmail.com>
> wrote:
>
>>
>>
>> Le 14 avr. 2020 =C3=A0 18:53, Nikita Popov <nikita.ppv@gmail.com> a =C3=
=A9crit :
>>
>> On Tue, Apr 14, 2020 at 6:07 PM Claude Pache <claude.pache@gmail.com>
>> wrote:
>>
>>>
>>>
>>> > Le 14 avr. 2020 =C3=A0 16:54, Nicolas Grekas <nicolas.grekas+php@gmai=
l.com>
>>> a =C3=A9crit :
>>> >
>>> > I'm just not sold on allowing "void" on __construct, because the very
>>> concept of a return type on a constructor is ... void, and also because=
 of
>>> the code style choices this will open (and the CS "wars" I mentioned).
>>> >
>>>
>>> This issue is not specific to magic method like __construct(). It is th=
e
>>> whole concept of =E2=80=9Cvoid=E2=80=9D as return type which is, say, =
=E2=80=9Cproblematic=E2=80=9D.
>>>
>>> In fact, =E2=80=9Cvoid=E2=80=9D is not really a return type. It is a wa=
y to state that
>>> the method is not supposed to return anything, which means, as you said
>>> very well, that =E2=80=9Cthe very concept of return type on [this metho=
d] is void=E2=80=9D.
>>>
>>> That might be a reason to reject the concept of =E2=80=9Cvoid=E2=80=9D =
as return type.
>>> Or to revive https://wiki.php.net/rfc/allow-void-variance <
>>> https://wiki.php.net/rfc/allow-void-variance> . But again, the issue is
>>> orthogonal to the fact that this particular method is magic, and we sho=
uld
>>> not cherry-pick and reject the concept of =E2=80=9Cvoid=E2=80=9D for __=
construct() and
>>> similar magic methods only.
>>
>>
>> Constructors not having a return type is standard behavior across most
>> (all?) languages. You can't specify a constructor return type in C++. Yo=
u
>> can't specify one in C#. You can't specify one in Java. Off-hand, I can'=
t
>> name a language that both has a first-class constructor concept (Rust's
>> "new" idiom does not count) and specifies a return type on it.
>>
>> It would naturally follow that, yes, you can't specify a constructor
>> return type in PHP either, just like we enforce right now. Unless we hav=
e
>> some strong reason to deviate from standard behavior that I do not see?
>>
>> Regards,
>> Nikita
>>
>>
>> Do those languages allow to return something from the constructor (as
>> does PHP currently)? because I=E2=80=99m more interested in the semantic=
s of `:
>> void` than the exact way to have it.
>>
>
> Ah, so that's what this is about! In that case, I'd be happy to simply
> always enforce that __construct() cannot return a value, in the same way =
we
> do for ": void" functions. (If we have backwards compatibility concerns, =
we
> can add this as a warning instead of hard error.)
>
> Nikita
>


I'll change the RFC and remove the `: void` return allowance for
`__construct()`. Should we do the same for `__destruct()`?

Nikita, about your suggestion of checking the actual return value of
`__construct()`, I've mentioned in the RFC that I want to do that for all
the magic methods in a future RFC (
https://wiki.php.net/rfc/magic-methods-signature#future-scope). Do you
think we can follow with that, or no, we should add this check to the
current RFC?

Nicolas, I've improved the RFC document. Let me know if there's anything
else that I need to clarify.

Thanks for the feedback y'all.

Best regards,

--000000000000dcf31305a3557161--