Hi >> The vote has now closed. >> >> The final result is 14 Yes, 12 No, which is less than the required 66%. >> The RFC is declined. >> > > Highly interesting to see that there's a theoretical path with a different > syntax that takes 4 voters to yes and change the outcome to 18/26, which > would have been an approved RFC. Working with readonly nowadays I can kinda > see how a-viz would be nice, but if I had a vote I'm also in the camp that > didn't like the syntax.
There was a poll during the discussion phase on syntax. https://externals.io/message/118557 So, there are two potential scenarios for what happened. 1. Enough people participated in the poll for a representative result (unlikely, there were only 11 people with voting karma in the poll) and this truly is the preferred syntax. 2. Not enough voters participated and the result is inaccurate. At this point there's really nothing we could've done. We asked for feedback in the RFC but didn't get any when it comes to syntax. I also contacted all people who voted no due to syntax but only got one response. So even now it's hard to understand if there's consensus on the preferred syntax for the no-due-to-syntax voters. IMO (not speaking for Larry here) this is a failure of the RFC process. Voters dislike secondary votes that aren't purely additive, thus making syntax a secondary vote wasn't really an option. However, many voters also don't participate in the discussion or read the RFC until the vote is announced. This makes it extremely difficult to understand the majority opinion. To be honest, I couldn't care less about what syntax is chosen. There are semantic differences between the Swift and C# approach that matter, as the C# approach makes working with arrays unnecessarily difficult. Sadly this discussion drowned which became evident by answering the same question repeatedly. Apart from that, any option would've done. I'm not sure if this is something we can improve in the RFC process. We don't want to discourage no votes just because people have limited time to participate. Nonetheless, weeks of work going down the drain for superficial reasons is also frustrating. Maybe something we could implement is requiring a rationale when voting against an RFC. I hope people who voted no due to syntax can still share their preferred option so that we know if this is worth revisiting in the future. Larry and I are also starting work on property hooks (a.k.a. accessors) at which point it might become more evident why asymmetric visibility is useful in the first place. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php