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 On Mon, 16 Aug 2021 at 10:04, Nikita Popov <nikita....@gmail.com> wrote: > 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 >
