Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110573
MIME-Version: 1.0
References: <CANeKSiR18yf7modMbr5ZB5XSe6a3MKwurdZeq9L2g3X=OpUYSA@mail.gmail.com>
 <CAFPFaMLx4XXmzCbfm-O-qoKxS9GA5FsN44H9vgHAzJ09L66mtg@mail.gmail.com> <CAH5C8xVH2RdPStkW8DsEYBCANT2KrE2_QKUFQy4+ZQRg4-1q3w@mail.gmail.com>
In-Reply-To: <CAH5C8xVH2RdPStkW8DsEYBCANT2KrE2_QKUFQy4+ZQRg4-1q3w@mail.gmail.com>
Date: Tue, 16 Jun 2020 12:26:07 +0300
Message-ID: <CANeKSiR=cD=J1eot5SmXWVqq-PC6mPjBg9im26WZBMM1hwGj1A@mail.gmail.com>
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: "G. P. B." <george.banyard@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d1752e05a830222b"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000d1752e05a830222b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey M=C3=A1t=C3=A9,

On Tue, Jun 16, 2020, 11:31 AM M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail.co=
m> wrote:
> Hi Benas,

> Overall, I'm very much in favour of disallowing returning a value from
constructors.
> However, I think the RFC should deal with the return value and the
signature validation
> in the same time, so that we can vote about both, since introducing the
latter check
> is not just a bug fix, it's a substantial change IMO.
>
> What I would like to avoid for sure is that the void return type is not
actually enforced.
> (Offtopic: It seems that the magic method signature RFC exactly does
this, and I'm not
> happy about it. I'd welcome an amendment RFC to fix the new
inconsistencies).

Since there was a second PR already in the works on dealing with the return
value, I wasn't sure whether it was a good idea to implement that. But, I'm
happy to join forces and will contact the PR's author :)

> Furthermore, I personally also like the concept of an explicit return
type declaration for
>constructors, but Nikita's earlier argument against (that most languages
forbid the explicit
> return type) makes me think. Anyhow, this counterargument might be worth
to add to the RFC.

I should have emphasized more on this but PHP constructors aren't like any
other language constructors, since they are normal methods that can be
called by simply doing `$object->__construct();`.

I'm not sure if any other language allows you to do something similar.

> And regarding the last section of the RFC (Backward Incompatible
Changes), I'm not exactly
> sure what you mean there, but since constructors are exempt to LSP
validation, I think
> it's ok if a child class overrides the parent constructor with a widened
return type.
>
> Regards,
> M=C3=A1t=C3=A9

What I meant, was that since no return type means `mixed|void`, you can't
do the following:
```
public function __construct(): mixed {}
```

But yes, it is allowed to widen the type from `void` to no return type.

Best regards,
Benas

--000000000000d1752e05a830222b--