Re: [RFC] Asymmetric Visibility, with readonly

> > > 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