# [VOTE] Nullable intersection types - Thread: https://externals.io/message/115700 - Original archive: https://news-web.php.net/php.internals/115700 - Started by Nicolas Grekas on 2021-08-13T09:35:05+00:00 - Messages: 21 - RFC: Nullable intersection types (Declined) — https://externals.io/rfc/nullable_intersection_types.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #115700 — Nicolas Grekas — 2021-08-13T09:35:05+00:00 URL: https://externals.io/message/115700#115700 Hi everyone, I'm happy to announce that the vote for nullable intersection types is now open: https://wiki.php.net/rfc/nullable_intersection_types It'll close in two weeks, on the 27th. Cheers, Nicolas --- ## #115701 — Marco Pivetta — 2021-08-13T11:30:07+00:00 URL: https://externals.io/message/115700#115701 · In reply to: #115700 Hey Nicolas, On Fri, Aug 13, 2021 at 11:35 AM Nicolas Grekas wrote: > Hi everyone, > > I'm happy to announce that the vote for nullable intersection types is now > open: > https://wiki.php.net/rfc/nullable_intersection_types > > It'll close in two weeks, on the 27th. > I voted NO on this one. I'm not opposed to nullable intersection types, but not in PHP 8.1. Specifically, I'm waiting for the first RC releases to land in September to even start looking at PHP 8.1 support for any of my projects, and stability is key. I also am not on board with the lack of design around reflection API here. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #115732 — Marco Pivetta — 2021-08-15T02:33:01+00:00 URL: https://externals.io/message/115700#115732 · In reply to: #115701 Heyo, just a follow-up. > Hey Nicolas, > > > On Fri, Aug 13, 2021 at 11:35 AM Nicolas Grekas > wrote: > > > […] > > I voted NO on this one. I'm not opposed to nullable intersection types, > but not in PHP 8.1. > > Specifically, I'm waiting for the first RC releases to land in September > to even start looking at PHP 8.1 support for any of my projects, and > stability is key. > > I also am not on board with the lack of design around reflection API here. > I just re-checked the RFC, and I'm completely against the reflection design in here (which I previously dismissed as "oversight"). An `(A&B)|null` is **not** a `ReflectionIntersectionType`, but should instead be a `ReflectionUnionType`. Therefore, adding this to the "NO" reasons, since we'll otherwise have to live with this mistake for many years to come. --- ## #115733 — drealecs@gmail.com — 2021-08-15T04:26:32+00:00 URL: https://externals.io/message/115700#115733 · In reply to: #115732 > Heyo, just a follow-up. > > > > > […] > here. > > […] > > I just re-checked the RFC, and I'm completely against the reflection design > in here (which I previously dismissed as "oversight"). > > An `(A&B)|null` is **not** a `ReflectionIntersectionType`, but should > instead be a `ReflectionUnionType`. > > > Therefore, adding this to the "NO" reasons, since we'll otherwise have to > live with this mistake for many years to come. > > Just to mention here, `A|null` is also not a `ReflectionUnionType` but a `ReflectionNamedType`, union with null already being a special case. https://3v4l.org/lM9NJ But the fact that these things might not be known clearly and the fact that nullability concept wasn't discussed and agreed on for the type system in general, I also think the feature can wait for 8.2. Alex --- ## #115741 — Patrick ALLAERT — 2021-08-15T23:46:10+00:00 URL: https://externals.io/message/115700#115741 · In reply to: #115700 Le ven. 13 août 2021 à 11:35, Nicolas Grekas a écrit : > Hi everyone, > > I'm happy to announce that the vote for nullable intersection types is now > open: > https://wiki.php.net/rfc/nullable_intersection_types > > It'll close in two weeks, on the 27th. > > Cheers, > Nicolas > Hi Nicolas, I am afraid that this is way too late for PHP 8.1. We are 2 weeks away from RC 1 and we are in feature freeze. I would recommend closing the vote and re-open it for PHP 8.2 unless I missed something that justifies breaking the feature freeze rule. @Joe, @Ben Ramsey : your opinion? Cheers, Patrick --- ## #115742 — Tobias Nyholm — 2021-08-16T00:03:55+00:00 URL: https://externals.io/message/115700#115742 · In reply to: #115741 > > > Le ven. 13 août 2021 à 11:35, Nicolas Grekas a > écrit : > > > […] > > Hi Nicolas, > > I am afraid that this is way too late for PHP 8.1. We are 2 weeks away from > RC 1 and we are in feature freeze. > > I would recommend closing the vote and re-open it for PHP 8.2 unless I > missed something that justifies breaking the feature freeze rule. > > @Joe, @Ben Ramsey : your opinion? > > Cheers, > Patrick Hey Patrick. This has been discussed already. See https://externals.io/message/115554 TLDR; This is not a feature. It is to correct a mistake which is exactly what the stabilisation phase is for. Some people still think this should be for 8.2. The discussion started 4(!) months before the release of 8.1. It is now more than 3(!) months before release of 8.1. Some people claim this is being “rushed”. I really don’t think that adding this patch 3 months before a release is “rushing it”. // Tobias --- ## #115743 — Marco Pivetta — 2021-08-16T00:07:57+00:00 URL: https://externals.io/message/115700#115743 · In reply to: #115742 Heyo, > It is to correct a mistake No mistake: the "pure intersection types" RFC was explicitly designed to avoid scope creep (this RFC). --- ## #115744 — Kalle Sommer Nielsen — 2021-08-16T00:09:41+00:00 URL: https://externals.io/message/115700#115744 · In reply to: #115742 > Hey Patrick. > > This has been discussed already. See https://externals.io/message/115554 Only Joe replied in there, implying an OK, however Patrick is also an RM and if he raises a concern, then that is good grounds for concern as exceptions to the feature freeze has to be approved by the RM for that branch -- exaclty what Patrick is. > > TLDR; This is not a feature. It is to correct a mistake which is exactly what the stabilisation phase is for. > Some people still think this should be for 8.2. > The discussion started 4(!) months before the release of 8.1. It is now more than 3(!) months before release of 8.1. The same argument could also have been made that there was 4 months of discussions without this being put forward, but let's not go down that path, the decision to halt this vote (if desired), is with the RMs, not the internal contributors. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #115745 — Tobias Nyholm — 2021-08-16T00:22:03+00:00 URL: https://externals.io/message/115700#115745 · In reply to: #115744 Hey. > No mistake: the "pure intersection types" RFC was explicitly designed to avoid scope creep (this RFC). Just because it was intentional, does not make it less of a mistake. I see that we have different views of this. And I understand that you are happy with this change, but only for 8.2. > the decision to halt this vote (if desired), is with the RMs, > not the internal contributors. Yes, naturally. Sorry if I implied something else. // Tobias --- ## #115746 — Patrick ALLAERT — 2021-08-16T01:22:07+00:00 URL: https://externals.io/message/115700#115746 · In reply to: #115742 Le lun. 16 août 2021 à 02:04, Tobias Nyholm a écrit : > > > > > Le ven. 13 août 2021 à 11:35, Nicolas Grekas a > écrit : > > Hi everyone, > > I'm happy to announce that the vote for nullable intersection types is now > open: > https://wiki.php.net/rfc/nullable_intersection_types > > It'll close in two weeks, on the 27th. > > Cheers, > Nicolas > > > Hi Nicolas, > > I am afraid that this is way too late for PHP 8.1. We are 2 weeks away from > RC 1 and we are in feature freeze. > > I would recommend closing the vote and re-open it for PHP 8.2 unless I > missed something that justifies breaking the feature freeze rule. > > @Joe, @Ben Ramsey : your opinion? > > Cheers, > Patrick > > > Hey Patrick. > > This has been discussed already. See https://externals.io/message/115554 > > TLDR; This is not a feature. It is to correct a mistake which is exactly > what the stabilisation phase is for. > Some people still think this should be for 8.2. > The discussion started 4(!) months before the release of 8.1. It is now > more than 3(!) months before release of 8.1. > > Some people claim this is being “rushed”. I really don’t think that adding > this patch 3 months before a release is “rushing it”. > > // Tobias > Thanks Tobias. My mail was sent a bit too fast as I do know why this is suggested for PHP 8.1 in the meantime. However I am not convinced enough by the various arguments I've seen for not considering it as a feature change. There's no black or white answer here as I understand it's kind of a special case. The current period is used for stabilization and changing something at the syntax level is not just a simple detail. External tools (IDE, linters, debuggers, tools manipulating stacktraces with arguments,...) may rely on that "stability" too and may have their own schedule impacted if they want to be ready for PHP 8.1 GA (Nov 25th). It would be a very unanimously accepted corner case change to an already voted RFC: it would be easy to accept it. But here I see something that is quite debated/debatable, being voted during holidays and potentially merged 5 days before tagging 8.1.0RC1. Those are risky ingredients IMHO. I know Joe would be ok with it ( https://github.com/php/php-src/pull/7259#issuecomment-883645872), but I'm personally not confident and don't know Ben's opinion on it yet. We (PHP 8.1 RMs) should discuss this together. While I am not currently in favor of it, I may change my mind in the next couple of days once I can forge a stronger opinion on it. Cheers, Patrick --- ## #115749 — Deleu — 2021-08-16T07:01:59+00:00 URL: https://externals.io/message/115700#115749 · In reply to: #115745 On Mon, Aug 16, 2021 at 2:22 AM Tobias Nyholm wrote: > Hey. > > > […] > avoid scope creep (this RFC). > > > Just because it was intentional, does not make it less of a mistake. > I see that we have different views of this. And I understand that you are > happy with this change, but only for 8.2. > > I hope one day I'll have built up so much experience, knowledge and confidence to call a 30 x 3 vote of the selective people that can cast a vote "a mistake". -- Marco Aurélio Deleu --- ## #115750 — Joe Watkins — 2021-08-16T07:45:21+00:00 URL: https://externals.io/message/115700#115750 · In reply to: #115749 Morning all, The initial RFC was clear that nullability was not supported, however that doesn't seem to be have widely understood. When I said we should move forward I did imagine that there was some consensus about the syntax we should use if we were to support nullability. As this conversation has progressed it has become clear that we don't have that consensus, and many people are just not comfortable trying to build consensus this late in the cycle. The RFC is not passing currently so I don't think we actually need to do anything, except prepare to deploy the feature that was voted in, pure intersections. The RFC should be allowed to complete, it's gathering important data. In the end, I'm not as happy to make an exception as I was when the discussion started. Cheers Joe > > On Mon, Aug 16, 2021 at 2:22 AM Tobias Nyholm > wrote: > > > […] > I hope one day I'll have built up so much experience, knowledge and > confidence to call a 30 x 3 vote of the selective people that can cast a > vote "a mistake". > > -- > Marco Aurélio Deleu --- ## #115751 — Joe Watkins — 2021-08-16T07:48:32+00:00 URL: https://externals.io/message/115700#115751 · In reply to: #115750 Please rearrange and add words as necessary, so that they makes sense :) "... however that doesn't seem to have been widely understood". Cheers Joe > Morning all, > > The initial RFC was clear that nullability was not supported, however that > doesn't seem to be have widely understood. > > When I said we should move forward I did imagine that there was some > consensus about the syntax we should use if we were to support nullability. > > As this conversation has progressed it has become clear that we don't have > that consensus, and many people are just not comfortable trying to build > consensus this late in the cycle. > > The RFC is not passing currently so I don't think we actually need to do > anything, except prepare to deploy the feature that was voted in, pure > intersections. > > The RFC should be allowed to complete, it's gathering important data. > > In the end, I'm not as happy to make an exception as I was when the > discussion started. > > Cheers > Joe > > > > > […] --- ## #115753 — Nikita Popov — 2021-08-16T08:03:55+00:00 URL: https://externals.io/message/115700#115753 · In reply to: #115750 > Morning all, > > The initial RFC was clear that nullability was not supported, however that > doesn't seem to be have widely understood. > > When I said we should move forward I did imagine that there was some > consensus about the syntax we should use if we were to support nullability. > Based on the vote, it looks like there's a pretty clear consensus on (X&Y)|null :) > As this conversation has progressed it has become clear that we don't have > that consensus, and many people are just not comfortable trying to build > consensus this late in the cycle. > > The RFC is not passing currently so I don't think we actually need to do > anything, except prepare to deploy the feature that was voted in, pure > intersections. > > The RFC should be allowed to complete, it's gathering important data. > > In the end, I'm not as happy to make an exception as I was when the > discussion started. FWIW I think that if we granted an exception for this once, we shouldn't go back on it. Maybe there should have been some discussion among RMs about this, but I think your agreement was interpreted (at least by me and presumably Nicolas) as it being fine to go forward with this RFC from a release management perspective. Now that the vote is underway, people can take the fact that this is targeting 8.1 into consideration in their choice -- I suspect that a lot of the "no" votes here are specifically due to that, not because they generally dislike support for nullable intersection types. As a meta note, I think it's important that we're open to minor changes to new features during the pre-release phase -- it's purpose is not just implementation stability. In fact, we can fix implementation bugs anytime, but usually can't do the same with design issues. (Of course, in this particular case the proposed change is backwards-compatible, so there is no strict requirement to make a change before the stable release.) Regards, Nikita --- ## #115756 — Joe Watkins — 2021-08-16T08:23:36+00:00 URL: https://externals.io/message/115700#115756 · In reply to: #115753 Morning Nikita, all, The exception was granted to ratify consensus that I thought we had - and that one of the two primary votes on the current RFC seems to support. However, the RFC we got was something that contained multiple primary votes - we must consider the first two votes primary, we don't want to choose syntax on a 50% majority. At the moment it looks like we don't have a consensus that adding nullability (at this late stage) is important. I too think it's important to be flexible in this stage of the cycle, but I look at the opposition to making this change now and that degrades my confidence that making the change this late even if it does pass is a good idea. Cheers Joe > > > > […] > > Based on the vote, it looks like there's a pretty clear consensus on > (X&Y)|null :) > > > > […] > > > FWIW I think that if we granted an exception for this once, we shouldn't > go back on it. Maybe there should have been some discussion among RMs about > this, but I think your agreement was interpreted (at least by me and > presumably Nicolas) as it being fine to go forward with this RFC from a > release management perspective. Now that the vote is underway, people can > take the fact that this is targeting 8.1 into consideration in their choice > -- I suspect that a lot of the "no" votes here are specifically due to > that, not because they generally dislike support for nullable intersection > types. > > As a meta note, I think it's important that we're open to minor changes to > new features during the pre-release phase -- it's purpose is not just > implementation stability. In fact, we can fix implementation bugs anytime, > but usually can't do the same with design issues. (Of course, in this > particular case the proposed change is backwards-compatible, so there is no > strict requirement to make a change before the stable release.) > > Regards, > Nikita --- ## #115765 — Nicolas Grekas — 2021-08-19T10:25:11+00:00 URL: https://externals.io/message/115700#115765 · In reply to: #115756 > > > > > […] > Morning Nikita, all, > > The exception was granted to ratify consensus that I thought we had - and > that one of the two primary votes on the current RFC seems to support. > > However, the RFC we got was something that contained multiple primary > votes - we must consider the first two votes primary, we don't want to > choose syntax on a 50% majority. > > At the moment it looks like we don't have a consensus that adding > nullability (at this late stage) is important. > > I too think it's important to be flexible in this stage of the cycle, but > I look at the opposition to making this change now and that degrades my > confidence that making the change this late even if it does pass is a good > idea. > > Cheers > Joe > What a mess! I feel so disappointed by the lack of clarity of the processes here. The RFC was granted a "go" by a release manager, but suddenly, in the middle of the vote, another release manager raised an objection to this grant!? This should have been discussed before between release managers. Also, this "go" is now apparently revoked based on the partial results of the vote. This is obviously interfering with the vote itself! I'm not blaming any individuals, but some processes should clarify how this is supposed to work. At least please coordinate together on such topics! 🙏 The processes also lack clarity about what the feature freeze is supposed to mean. We're having a metadiscussion about whether this RFC can target 8.1 or not, and many ppl stated that they would vote against it not because they don't want nullability, but because they don't want it in 8.1, or because they feel it's too late for 8.1. I can't blame them for that, but what is "feature freeze" supposed to mean if we aren't allowed to discuss, alter, or even revert not-yet-released features?!? This should be shielded by some consensus on what is allowed during the feature freeze. On my side: anything that is not yet released should be re-discussable until either beta or RC stage. If we choose to go with beta, we should give more time between the start of the feature freeze and the first beta, precisely to fix what happened to this RFC, aka to give a window for the community (me here) to play with the soon-to-be features and give feedback. 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. ¯\_(ツ)_/¯ 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. Please advise (release managers mainly I suppose, since you're the only ones having some sort of official authority here). Nicolas --- ## #115770 — Patrick ALLAERT — 2021-08-22T22:42:24+00:00 URL: https://externals.io/message/115700#115770 · In reply to: #115765 Hi Nicolas, Le jeu. 19 août 2021 à 12:25, Nicolas Grekas a écrit : > What a mess! I feel so disappointed by the lack of clarity of the > processes here. > You aren't alone and it is challenging to make that kind of decision. I would have been more confident saying it's ok if the process and feature freeze was clear about the fact that even syntax changes are allowed a couple of days before a RC1 provided that it touches a new feature. > The RFC was granted a "go" by a release manager, but suddenly, in the > middle of the vote, another release manager raised an objection to this > grant!? > I'm sorry for the timing and I was also not aware of it. > This should have been discussed before between release managers. > Agreed! That would have been ideal. > Also, this "go" is now apparently revoked based on the partial results of > the vote. This is obviously interfering with the vote itself! I'm not > blaming any individuals, but some processes should clarify how this is > supposed to work. At least please coordinate together on such topics! 🙏 > > The processes also lack clarity about what the feature freeze is supposed > to mean. We're having a metadiscussion about whether this RFC can target > 8.1 or not, and many ppl stated that they would vote against it not because > they don't want nullability, but because they don't want it in 8.1, or > because they feel it's too late for 8.1. I can't blame them for that, but > what is "feature freeze" supposed to mean if we aren't allowed to discuss, > alter, or even revert not-yet-released features?!? > I share with you the lack of clarity. Commenting on the various aspects of feature freeze (personal pov): - discuss: discussing shouldn't be prevented in any way, never. - alter: that is the most touchy part as alteration might be about very various levels: edge cases, implementation details, conceptual ones, syntax,... In a feature freeze, I would only consider minor changes that wouldn't have influenced the way people would have voted the RFC. That would exclude any conceptual changes as well as syntax ones. - revert: if there are evidence that something that has been voted "yes" really brings unforeseen challenges and provided that a majority would recognize something that has been accepted should better be reverted, I think we must be open to revert the introduction of a new feature: better not having a new (buggy?) feature than a solid one later. In the case of your new RFC: I rather see it as another feature on top of a new one that even requires syntax changes. It may prove that the original one was not rock-solid enough but it may also be seen as an extension of it. > This should be shielded by some consensus on what is allowed during the > feature freeze. On my side: anything that is not yet released should be > re-discussable until either beta or RC stage. If we choose to go with beta, > we should give more time between the start of the feature freeze and the > first beta, precisely to fix what happened to this RFC, aka to give a > window for the community (me here) to play with the soon-to-be features and > give feedback. > 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. > 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. > 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 understand you Nicolas. Let me and the other RMs have a chat about that so that we explore all the possible options > Please advise (release managers mainly I suppose, since you're the only > ones having some sort of official authority here). > > Nicolas > Cheers, Patrick --- ## #115775 — Larry Garfield — 2021-08-23T14:21:37+00:00 URL: https://externals.io/message/115700#115775 · In reply to: #115770 > 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. > > […] > > 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. > > […] 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 --- ## #115777 — Deleu — 2021-08-23T15:11:30+00:00 URL: https://externals.io/message/115700#115777 · In reply to: #115765 On Thu, Aug 19, 2021 at 12:25 PM Nicolas Grekas wrote: > What a mess! I feel so disappointed by the lack of clarity of the > processes here. > > The RFC was granted a "go" by a release manager, but suddenly, in the > middle of the vote, another release manager raised an objection to this > grant!? This should have been discussed before between release managers. > Also, this "go" is now apparently revoked based on the partial results of > the vote. This is obviously interfering with the vote itself! I'm not > blaming any individuals, but some processes should clarify how this is > supposed to work. At least please coordinate together on such topics! 🙏 > > The processes also lack clarity about what the feature freeze is supposed > to mean. We're having a metadiscussion about whether this RFC can target > 8.1 or not, and many ppl stated that they would vote against it not because > they don't want nullability, but because they don't want it in 8.1, or > because they feel it's too late for 8.1. I can't blame them for that, but > what is "feature freeze" supposed to mean if we aren't allowed to discuss, > alter, or even revert not-yet-released features?!? This should be shielded > by some consensus on what is allowed during the feature freeze. On my side: > anything that is not yet released should be re-discussable until either > beta or RC stage. If we choose to go with beta, we should give more time > between the start of the feature freeze and the first beta, precisely to > fix what happened to this RFC, aka to give a window for the community (me > here) to play with the soon-to-be features and give feedback. > > 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. ¯\_(ツ)_/¯ > > 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. > > Please advise (release managers mainly I suppose, since you're the only > ones having some sort of official authority here). > > Nicolas > All things considered I think the outcome was somewhat expected. The grant given was "with the best knowledge at the time of the grant" which obviously is subject to change given how much discussion happened for the RFC. The discussion presented resistance to the change and the vote reflects the sentiment around the discussion. The fact that the process could be better doesn't make it a mess. Ultimately, the language syntax is how we communicate with the computer and more importantly how we read and understand the code. It has a great impact on code using `token_get_all()` and is always a delicate matter. An RFC targeting controversial syntax change in post feature-freeze is ... challenging. -- Marco Aurélio Deleu --- ## #115821 — Nicolas Grekas — 2021-08-25T16:40:07+00:00 URL: https://externals.io/message/115700#115821 · In reply to: #115775 Le lun. 23 août 2021 à 16:22, Larry Garfield a écrit : > > > > […] > 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. > > > > […] > the > > […] > that > > […] > data > > […] > Apparently, we > > […] > even > > […] > > 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. > > > […] > for > > […] > withdraw > > […] > conditions > > […] > > 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. > No need to disagree as I was referring to exactly that: the legality of the vote. This legality has been deeply challenged during the discussion period and during the vote itself. That's what I'm referring to as interference. Once the legality is shielded, of course ppl are free to vote what they want. That wasn't the case at all for this RFC. I wish we'll find a way to not experience this confusion anymore in the future. Nicolas --- ## #115886 — Nicolas Grekas — 2021-08-27T20:19:20+00:00 URL: https://externals.io/message/115700#115886 · In reply to: #115700 Hi everyone, I'm happy to announce that the vote for nullable intersection types is now > open: > https://wiki.php.net/rfc/nullable_intersection_types > > It'll close in two weeks, on the 27th. > The vote is now closed with a total of 38 votes: 26 against and 12 in favor. The RFC is declined. Nicolas