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
Hey Nicolas,
On Fri, Aug 13, 2021 at 11:35 AM Nicolas Grekas nicolas.grekas@gmail.com
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_typesIt'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
Heyo, just a follow-up.
Hey Nicolas,
On Fri, Aug 13, 2021 at 11:35 AM Nicolas Grekas nicolas.grekas@gmail.com
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_typesIt'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.
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.
Heyo, just a follow-up.
Hey Nicolas,
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)|nullis not aReflectionIntersectionType, but should
instead be aReflectionUnionType.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
Le ven. 13 août 2021 à 11:35, Nicolas Grekas nicolas.grekas@gmail.com 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_typesIt'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 ben@benramsey.com: your opinion?
Cheers,
Patrick
Le ven. 13 août 2021 à 11:35, Nicolas Grekas nicolas.grekas@gmail.com 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_typesIt'll close in two weeks, on the 27th.
Cheers,
NicolasHi 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 ben@benramsey.com: your opinion?
Cheers,
Patrick
Hey Patrick.
This has been discussed already. See https://externals.io/message/115554 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
Heyo,
It is to correct a mistake
No mistake: the "pure intersection types" RFC was explicitly designed to
avoid scope creep (this RFC).
Hey Patrick.
This has been discussed already. See https://externals.io/message/115554 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
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
On Mon, Aug 16, 2021 at 2:22 AM Tobias Nyholm tobias.nyholm@gmail.com
wrote:
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.
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
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 tobias.nyholm@gmail.com
wrote: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.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
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
JoeOn Mon, Aug 16, 2021 at 2:22 AM Tobias Nyholm tobias.nyholm@gmail.com
wrote: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.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
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
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
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
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
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
Hi Nicolas,
Le jeu. 19 août 2021 à 12:25, Nicolas Grekas nicolas.grekas@gmail.com 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
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
Le lun. 23 août 2021 à 16:22, Larry Garfield larry@garfieldtech.com a
écrit :
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.
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
On Thu, Aug 19, 2021 at 12:25 PM Nicolas Grekas nicolas.grekas@gmail.com
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
Le lun. 16 août 2021 à 02:04, Tobias Nyholm tobias.nyholm@gmail.com a
écrit :
Le ven. 13 août 2021 à 11:35, Nicolas Grekas nicolas.grekas@gmail.com 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_typesIt'll close in two weeks, on the 27th.
Cheers,
NicolasHi 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 ben@benramsey.com: your opinion?
Cheers,
PatrickHey 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
Hi everyone,
I'm happy to announce that the vote for nullable intersection types is now
open:
https://wiki.php.net/rfc/nullable_intersection_typesIt'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