Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124469
Precedence: bulk
MIME-Version: 1.0
References: <CABY-Mhz36WtLx_1bWAmK8rUpqAQTEw3H1mziPa5TH4nEgeHYFg@mail.gmail.com>
 <CANLbj-pk9FmHKG+PZcK-ua1DGKbHJ6wtsCKedKJdMSJZdM+aPw@mail.gmail.com>
In-Reply-To: <CANLbj-pk9FmHKG+PZcK-ua1DGKbHJ6wtsCKedKJdMSJZdM+aPw@mail.gmail.com>
Reply-To: lilybergonzat+php@gmail.com
Date: Thu, 18 Jul 2024 11:49:27 +0200
Message-ID: <CAPPUTHo-pfQNK_CKGTMm8fj1=VJaLvk5Y2iRpbCewuNBY48sSw@mail.gmail.com>
Subject: Re: [PHP-DEV] Optional constructor body
To: Ayesh Karunaratne <ayesh@php.watch>
Cc: Oliver Nybroe <olivernybroe@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: lilybergonzat+php@gmail.com (Lily Bergonzat)

I don't view this proposition as a breaking change. The way I
understand it, writing an empty body for a constructor would
still work, but we would also get the option to just omit the
body altogether.

I think it would be a very sensible update. I also think it should
require a semicolon, just so we have the same kind of syntax
as interfaces.

I would love to see such a change!

On Thu, Jul 18, 2024 at 11:46=E2=80=AFAM Ayesh Karunaratne <ayesh@php.watch=
> wrote:
>
> >
> > Hello internals.
> >
> > I am looking into making the constructor body optional in classes, esse=
ntially 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 foll=
owing way
> >
> > ```
> > class User {
> >     public function __construct(
> >         public string $name,
> >     ) {}
> > }
> > ```
> >
> > With the introduction or constructor property promotion in 8.0, we ofte=
n see classes where the constructor has an empty body, and my guess would b=
e that this will only increase with the introduction of property access hoo=
ks 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 c=
ode by removing two redundant characters.
> >
> >
> >
> > This would be my first RFC and I am willing to try and implement it mys=
elf.
> >
> >
> > 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.