Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124468
Precedence: bulk
MIME-Version: 1.0
References: <CABY-Mhz36WtLx_1bWAmK8rUpqAQTEw3H1mziPa5TH4nEgeHYFg@mail.gmail.com>
In-Reply-To: <CABY-Mhz36WtLx_1bWAmK8rUpqAQTEw3H1mziPa5TH4nEgeHYFg@mail.gmail.com>
Date: Thu, 18 Jul 2024 16:40:05 +0700
Message-ID: <CANLbj-pk9FmHKG+PZcK-ua1DGKbHJ6wtsCKedKJdMSJZdM+aPw@mail.gmail.com>
Subject: Re: [PHP-DEV] Optional constructor body
To: Oliver Nybroe <olivernybroe@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: ayesh@php.watch (Ayesh Karunaratne)

>
> Hello internals.
>
> I am looking into making the constructor body optional in classes, essent=
ially allowing you to write
>
> ```
> class User {
>     public function __construct(
>         private string $name,
>     )
> }
> ```
>
> Currently to make this code valid, it would have to be written the follow=
ing way
>
> ```
> class User {
>     public function __construct(
>         public string $name,
>     ) {}
> }
> ```
>
> With the introduction or constructor property promotion in 8.0, we often =
see classes where the constructor has an empty body, and my guess would be =
that this will only increase with the introduction of property access hooks=
 in 8.4 which is allowed to be defined in the constructor also.
>
> This change would only be a cosmetic change and simplify the userland cod=
e by removing two redundant characters.
>
>
>
> This would be my first RFC and I am willing to try and implement it mysel=
f.
>
>
> Best regards
> Oliver Nybroe (he/him)

Hi Oliver,

Some links to previous discussions when this was brought up in the
mailing list before:

 - https://externals.io/message/114324
 - https://externals.io/message/111590

I followed those discussions closely back then, and I suppose the
general sentiment (to which I also agree) was that this is more of a
code style consideration rather than a technical one. Although it's a
cosmetic change, the fact that it will cause BC issues on older PHP
versions was a significant concern; now more so after we had
Constructor Properties for 4 years.

I think you can gather more pre-RFC opinions from this mailing thread,
especially now that this is brought up after a while since Constructor
Properties were introduced.

If you do with to go with an RFC, I'd like to see if your proposal
addresses whether this syntax should implicitly call
`parent::__construct()`, and if a semi colon is expected or not
(`public function __construct(public int $foo);` vs `public function
__construct(public int $foo)`).

Ayesh.