>
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
