> > > 2. `readonly` is a "write once" flag that may be combined with asymmetric > visibility. If no set visibility is specified, `readoly` implies > `private(set)`, but a different set visibility may also be provided. > > These are both reasonable rules. However, it creates a conflict. > Specifically, in the following cases: > > public public(set) readonly string $foo > > protected protected(set) readonly string $foo >
What if the implicit rule for `readonly` is changed into `protected(set)`? Let's run with this for a minute. 1- It's not truly a CODE breaking change. Right now if you have a `protected readonly` property, you're either calling the parent constructor or you're never making use of the variable, otherwise you're getting a Fatal Error. 2- It's a CONCEPTUAL breaking change. If you've declared a `protected readonly` property, you may expect anyone in the inheritance chain to be calling your constructor. A new PHP version will warn you to either change your property into `protected private(set) readonly` (Rector might be able to do this) or accept the new behavior. 3- The two logical design choices can be kept. To be honest, I think asymmetric visibility seems way over complex for very little benefit, so I'm a bit against the entire feature, but if we were to have them, it would really be nicer to not have crazy shenanigans involved. -- Marco Deleu
