Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119227
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730
Mime-Version: 1.0
Message-ID: <845495d8-52da-4d2e-90ee-79c697d87f30@app.fastmail.com>
In-Reply-To: <3d8561bd-fdb1-417a-836b-5146fca56185@app.fastmail.com>
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <831b9906-dc0c-420c-b22f-8a0cc8a1ad64@app.fastmail.com>
 <454c5329-d5a3-5174-d09c-346b7d65435c@bastelstu.be>
 <8f9cf24c-ee77-4227-9b7c-31c631bf8a72@app.fastmail.com>
 <84647C1B-0F61-41E5-981D-B860BE1E53CB@gmail.com>
 <EB4F7DA5-A526-4E9C-ADF0-31DE86B7368F@gmail.com>
 <3d8561bd-fdb1-417a-836b-5146fca56185@app.fastmail.com>
Date: Wed, 04 Jan 2023 14:28:47 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Dec 21, 2022, at 3:23 PM, Larry Garfield wrote:
> On Tue, Dec 13, 2022, at 11:03 AM, Claude Pache wrote:
>>> Le 13 d=C3=A9c. 2022 =C3=A0 16:34, Claude Pache <claude.pache@gmail.=
com> a =C3=A9crit :
>>>=20
>>>=20
>>> Hi,
>>>=20
>>> As of today, the following declarations are rejected as syntax error=
s:
>>>=20
>>> ```php
>>> class C {
>>>     $a;
>>>     int $b;
>>> }
>>> ```
>>>=20
>>> while the following declarations are accepted with implicit `public`=
 visibility:
>>>=20
>>> ```php
>>> class C {
>>>     static $c;
>>>     readonly int $d;
>>> }
>>> ```
>>>=20
>>> It would be reasonable to propose to allow to consistently omit the =
`public` keyword. But allowing to omit it in some cases (including the m=
ost controversial one: `protected(set)`) and not in other cases...? Beca=
use of this inconsistency, people are incited to always write explicitly=
 `public` anyway.
>>>=20
>>> =E2=80=94Claude
>>
>>
>> However, I=E2=80=99m just realising that omitting `public` in declara=
tions like=20
>> `public $a` and `public int $b` is probably not a good idea, because =
it=20
>> is incompatible with constructor property promotion, as `function=20
>> __construct(public int $b) { }`, and `function __construct(int $b) { =
}`=20
>> have different meanings.
>>
>> =E2=80=94Claude
>
> Well, it seems the only people who have opinions on the abbreviated=20
> form at all dislike it, so we've removed it for now and left a mention=20
> in future-scope.  A future RFC can add that if desired.
>
> That should, I think, be the final change to the asymmetric visibility=20
> RFC.  Baring anything else coming up, I expect to call the vote=20
> sometime the week of 2 January.
>
> Happy $holiday!
>
> --Larry Garfield

Happy New Year, PHP.  Fair warning, I will be opening the vote for asymm=
etric visibility on Friday, baring any sudden new inputs in the next 40-=
ish hours.

--Larry Garfield