On Fri, Aug 27, 2021 at 11:11 AM Tobias Nyholm firstname.lastname@example.org>
> But I do agree with you. The process would have been way better if they
> said âno". Or if they clearly and unanimously said âyesâ which would remove
> focus on âit feels rushedâ and âwe canât because of feature freezeâ.
> This is the the extended power I would like the RMs (as a group) to have.
> To be clear, Im not suggesting they should veto every RFC. Just changes
> during feature freeze. Since RMs are experienced open source developers, Im
> sure they know to ask for help privately whenever they need it.
> // Tobias
I do not believe the reason people felt it was rushed is because of
ambiguity from RMs. The reason people felt it was rushed is because:
1. It was a special case of combination types, which voters understood to
be a feature targeting 8.2
2. Because it was a feature understood to be targeting 8.2, there was
insufficient research into what was technically possible or favorable for
general combination types.
3. Because it was a feature understood to be targeting 8.2, it had been
specifically excluded from the intersection types RFC.
None of those would have been addressed by anything from the RMs, because
all of those have to do with the voters' understanding of what the roadmap
is and what they had previously voted on. The people who had voted to
include intersection types had very specifically been told that they were
not nullable, and voted for it anyway, knowing that nullability would come
when anticipated support for combination types came.
This is my understanding of the situation, in any case.