Re: [RFC] Asymmetric Visibility, with readonly

> > public public(set) readonly string $foo > > protected protected(set) readonly string $foo > > These would be the only way to have a non-private-set readonly property. While the first is in > practice quite unlikely, the second has valid use cases. Both have use cases. Whether they are valid is quite subjective. (I am speaking as someone who suffer from the match() construct forbidding having both default and some other case pointing to the same expression. That restriction seemed reasonable the time the feature was designed and voted.) > > 1. Relax the set-is-tighter restriction. That would allow protected > protected(set) etc. on any property. It wouldn't be particularly useful unless > readonly is being used, but it would be syntactically legal and behave as you'd expect. We > could still disallow "set is more permissive" combinations (eg, private > public(set)), as those have no apparent use case. I think that Option 1 is the most reasonable. The meaning of public public(set) and protected protected(set) is straightforward; from a user point-of-view, disallowing them seems more like “it is useless” than “it is confusing”. Unless there are good technical reason to restrict it, we can just leave to linting tools the care of reporting it. —Claude