Re: [RFC] Asymmetric Visibility, with readonly

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.pache@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