Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109638
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>
In-Reply-To: <0A374409-6FA6-4E02-A7E6-EACA3E42451C@gmail.com>
Date: Tue, 14 Apr 2020 18:53:44 +0200
Message-ID: <CAF+90c8wKkaT_2NdeHB0VOUmBnAEfaKsBDbaOEa1s8Z_arPyPA@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>, 
	Gabriel Caruso <carusogabriel34@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000debc0105a3430b48"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Ensure correct magic methods'
 signatures when typed
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000debc0105a3430b48
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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@gmail.=
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 o=
f
> 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 the
> 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 way =
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 method] is v=
oid=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 shoul=
d
> not cherry-pick and reject the concept of =E2=80=9Cvoid=E2=80=9D for __co=
nstruct() 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++. You
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 have some
strong reason to deviate from standard behavior that I do not see?

Regards,
Nikita

--000000000000debc0105a3430b48--