Re: [RFC] Nullable intersection types

On Sat, Jul 24, 2021, 07:33 Tobias Nyholm <tobias.nyholm@gmail.com> wrote: > > >>> Given both of these sets of assertions I would ask the RFC's author > and proponents what would be a worse outcome? > >> > >> I don’t see how this question is relevant. We are not seeking > compromises at the moment. We are seeking the best technical solution to a > technical issue. > The very essence of this whole RFC is rooted in compromise. This is a new feature being discussed after feature freeze. If best technical solution is what we should seek, then this discussion should target 8.2. > > > That is a strange attitude. You are saying that you rather see a release > with a know flaw than actually trying to find the best solution. > The release will be in 4 months. There is a process to clearly find issues > like this. There is plenty of time to review this RFC and release it in > beta 2 and let people test it. This is not a last minute thing, the process > is designed for this. Where does it say that feature freeze exists so that more features can be built after the freeze? > > So the “real world examples” you are looking for is: > If we don’t merge a version of this RFC in 8.1, PHP packages will not take > leverage of the inspection types until PHP 8.2. > > As the RFC states and Benjamin made extra clear, this is exactly what > happened with PHP 7.0. > And that's OK! Pure Intersection was voted that way 30 against 3 the way that it was! You can steer clear from intersection in libraries on 8.1 and use it on application code only, provide feedback and be part of a healthier discussion when extending its capabilities to cover what libraries need at a later stage.