On Sun, Aug 22, 2021, at 5:42 PM, Patrick ALLAERT wrote: > Either extra time, or having a way to influence the schedule of the > releases. > For now, we work with a fixed schedule and don't know (at least: me) how > strict we must stick to it. > > The fixed schedule of the releases is what makes me more comfortable with > the idea of reverting a new feature rather than extending the scope of one.
Speaking from the outside: Joe stated in an earlier email very clearly that because this was viewed as a "possible bug fix" it was given permission to run post-freeze. There was no dispute in my mind at least whether the RFC was valid. That said, if voters are of the opinion that "the cure is worse than the disease" on this one (eg, because it didn't take into account larger questions around compound types that will have to come later, and so may make things more difficult in the future, or because the reflection API isn't fully thought through, etc.), or that it feels too rushed, that is entirely their right to vote no on it on those grounds. That's basically a summary of my No vote: I'd rather have non-nullable intersections for now than something that is going to make life more difficult in the future for full mixed types. > > Based on the partial results of the vote, we could conclude that the > > consensus is to 1. not allow nullability and 2. force bracket around > > (X&Y)|null. I can't read this as anything else than ppl voting not on the > > RFC, but on this metadiscussion about the feature freeze + some fear that > > we might put ourselves in a corner with the syntax. > > > > The RFC should be allowed to complete, it's gathering important data. > >> > > > > Because of what I just wrote about, I don't think we can rely on any data > > here. The discussion should be rebooted from scratch for me. Apparently, we > > need the full syntax for composite types to decide for the syntax for > > nullable intersection types. ¯\_(ツ)_/¯ > > > > I also think that we can't rely on the data for the reason you mention even > if I intended to vote "no" on the feature, not on the targeted version of > PHP, I may be the exception there. That's not different than any other RFC. We never differentiate "no on the concept" from "no on the implementation" from "no on some particular detail that's really really important." That's data we almost never get, unless someone volunteers it on their own. This RFC is no different in that regard. > > Now, I don't know what to do. The vote started and is not looking good for > > the proposal. Some will say that I didn't want to see it fail if I withdraw > > it. But honestly, with all those interferences, I'm not sure the conditions > > are met to have a fair vote. I have to disagree. Given Joe's earlier message, the RFC was legal and allowed to proceed. "I still think it's too late" is entirely someone's right to justify a No vote. That's not interference, that's the voter's viewpoint and it should be respected. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
