Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110611
To: Benas IML <benas.molis.iml@gmail.com>,
 PHP Internals List <internals@lists.php.net>
References: <CANeKSiR18yf7modMbr5ZB5XSe6a3MKwurdZeq9L2g3X=OpUYSA@mail.gmail.com>
 <CANeKSiTikOJGcsGYgqYKJ9RCHpyyhyD66D7N2YRFGRHcqL7v0Q@mail.gmail.com>
Message-ID: <2802d206-cd92-0dd1-137a-caf0a5236519@gmx.de>
Date: Tue, 16 Jun 2020 22:57:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CANeKSiTikOJGcsGYgqYKJ9RCHpyyhyD66D7N2YRFGRHcqL7v0Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [RFC] [DISCUSSION] Allow void return type for
 constructors/destructors
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 16.06.2020 at 21:30, Benas IML wrote:

> I put the original RFC on hold and created a new PR [0] for implicitly
> enforcing `void` rules on both constructors and destructors. Note, that
> this results in a BC break since it is no longer legal to return non-voi=
d
> value from constructors/destructors. In other words, it is now illegal t=
o
> return something from ctor.
>
> As a side bonus, it is also allowed to explicitly declare both
> `__construct()` and `__destruct()` as `void` (but this is by no means
> mandatory, it's optional).
>
> I'm not sure whether this needs a proper RFC since this is more of a pat=
ch
> (fix: #79679) than a new feature, so let me know!
>
> This PR should also address all of M=C3=A1t=C3=A9's concerns since it ma=
kes
> constructors and destructors always return `void` (even when no explicit
> `void` return type is specified).

Thanks, I tend to prefer this solution.  Given the potential BC break
(constructors may be called like normal methods, so returning something
can make sense), I think an RFC is justified.

=2D-
Christoph M. Becker