> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: > Asymmetric Visibility. > > https://wiki.php.net/rfc/asymmetric-visibility > > Details are in the RFC, but it's largely a copy of Swift's support for the > same. >
Thank you Larry and Ilija for this RFC. After reading it, I'm wondering about inheritance rules. What would be the rules when redeclaring an existing asymmetric property in a child class? The RFC should mention them I believe. But I'm also wondering about the use case where asymmetry would be useful in practice now that we have readonly? I voted against readonly at the time because it didn't address cloning, and also because it deprives end-users vs code authors IMHO (alike "final"). I would have very much prefered asymmetric visibility back then. But now that we are here, what are the use cases? If it's cloning only, then I would very much prefer finding a way to fix it rather than providing two subtly different ways to achieve the same thing. Eg can't we allow __clone methods to bypass the readonly restrictions? The engine already handles "guards" when using magic property accessors. Can't we use something similar for clone? And if yes, what would remain of the motivations for the asymmetric RFC? Cheers, Nicolas
