Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109644
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>
In-Reply-To: <436FD800-A316-4C99-8793-C6EF4BD15BE3@gmail.com>
Date: Wed, 15 Apr 2020 12:56:54 +0200
Message-ID: <CAF+90c8uO2KcO8t=syX+4GMMda62K6gsfpW+FCC22VVNLv+_Jw@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="0000000000008e778505a3522d04"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Ensure correct magic methods'
 signatures when typed
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000008e778505a3522d04
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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@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 =
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 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 void=E2=80=9D.
>>
>> That might be a reason to reject the concept of =E2=80=9Cvoid=E2=80=9D a=
s 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 shou=
ld
>> not cherry-pick and reject the concept of =E2=80=9Cvoid=E2=80=9D for __c=
onstruct() 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
>
>
> Do those languages allow to return something from the constructor (as doe=
s
> PHP currently)? because I=E2=80=99m more interested in the semantics 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

--0000000000008e778505a3522d04--