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éc. 2022 à 16:34, Claude Pache <claude.pa...@gmail.com> a écrit :
>>>
>>>
>>> Hi,
>>>
>>> As of today, the following declarations are rejected as syntax errors:
>>>
>>> ```php
>>> class C {
>>> $a;
>>> int $b;
>>> }
>>> ```
>>>
>>> while the following declarations are accepted with implicit `public`
>>> visibility:
>>>
>>> ```php
>>> class C {
>>> static $c;
>>> readonly int $d;
>>> }
>>> ```
>>>
>>> It would be reasonable to propose to allow to consistently omit the
>>> `public` keyword. But allowing to omit it in some cases (including the most
>>> controversial one: `protected(set)`) and not in other cases...? Because of
>>> this inconsistency, people are incited to always write explicitly `public`
>>> anyway.
>>>
>>> —Claude
>>
>>
>> However, I’m just realising that omitting `public` in declarations like
>> `public $a` and `public int $b` is probably not a good idea, because it
>> is incompatible with constructor property promotion, as `function
>> __construct(public int $b) { }`, and `function __construct(int $b) { }`
>> have different meanings.
>>
>> —Claude
>
> Well, it seems the only people who have opinions on the abbreviated
> form at all dislike it, so we've removed it for now and left a mention
> in future-scope. A future RFC can add that if desired.
>
> That should, I think, be the final change to the asymmetric visibility
> RFC. Baring anything else coming up, I expect to call the vote
> sometime the week of 2 January.
>
> Happy $holiday!
>
> --Larry Garfield
Happy New Year, PHP. Fair warning, I will be opening the vote for asymmetric
visibility on Friday, baring any sudden new inputs in the next 40-ish hours.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
