On Mon, Aug 16, 2021 at 9:45 AM Joe Watkins <krak...@gmail.com> wrote:
> 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
