Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110606
MIME-Version: 1.0
References: <CANeKSiR18yf7modMbr5ZB5XSe6a3MKwurdZeq9L2g3X=OpUYSA@mail.gmail.com>
In-Reply-To: <CANeKSiR18yf7modMbr5ZB5XSe6a3MKwurdZeq9L2g3X=OpUYSA@mail.gmail.com>
Date: Tue, 16 Jun 2020 22:30:56 +0300
Message-ID: <CANeKSiTikOJGcsGYgqYKJ9RCHpyyhyD66D7N2YRFGRHcqL7v0Q@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d587fb05a8389540"
Subject: Re: [RFC] [DISCUSSION] Allow void return type for constructors/destructors
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000d587fb05a8389540
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey internals,

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-void
value from constructors/destructors. In other words, it is now illegal to
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 patch
(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 makes
constructors and destructors always return `void` (even when no explicit
`void` return type is specified).

Best regards,
Benas Seliuginas

On Tue, Jun 16, 2020, 3:34 AM Benas IML <benas.molis.iml@gmail.com> wrote:

> Hey internals,
>
> I am proposing to allow void return type for constructors/destructors.
> Note,
> that this is an **optional** and cosmetic-only addition! All of the
> reasoning
> is in the RFC.
>
> RFC: https://wiki.php.net/rfc/constructor_return_type
>
> Best regards,
> Benas
>

--000000000000d587fb05a8389540--