Re: [RFC] Asymmetric Visibility, with readonly

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