This is not a new feature. This is a detail of a feature that was not well understood for whatever reason.
That is why we are willing to fix it after freeze. I would ask anyone voting to vote on the basis of the detail and leave timing to be the problem of release managers. Voting negatively because you don't agree that we should fix it at this time might be considered harmful (to the feature, which we already accepted). Cheers Joe On Saturday, 24 July 2021, Mike Schinkel <m...@newclarity.net> wrote: > > On Jul 24, 2021, at 1:33 AM, Tobias Nyholm <tobias.nyh...@gmail.com> > wrote: > >> If you are not willing to compromise you will probably get nothing. > >> > >> It is relevant because I was trying to get you to ask yourself if you > would be happier if you get half of what you want rather than none of what > you want. > >> > >> Because there is a very real possibility you will get none of what you > want if the RFC requires the syntax so many have objected to. > >> > >> BTW, I do not have a strong opinion either way, but since I see than > many do have a strong opinion I was trying to play arbitrator between two > sets of people who each have very entrenched opinions where their opinions > are in conflict. If neither side will budge, nobody wins. > > > > > > 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. > > That is begging the question. It is not a "known flaw" — it is a perfectly > fine option — it is just not your preference. Arguing the syntax is > squarely in the realm of bike-shedding. > > >> That message mentioned the need in abstract, but it did not provide any > real-world examples. It claims that there were real-world examples, but > did not show any. > >> > >> That message was also not part of the RFC. > > > > The first paragraph under “Rational” mentioned this: > https://wiki.php.net/rfc/nullable_intersection_types#rationale < > https://wiki.php.net/rfc/nullable_intersection_types#rationale> > I see no code examples showing real-world use-cases in the "Rational" > section, I just see an abstract assertion by the author explain why they > believe it is needed. > > I don't get the pushback on providing real-world use-case examples. > Clearly with your work in Symfony — given the assumption that nullable > intersection types are really needed — you must has at least a few > examples. Why not provide them? > > > In my world maintaining PHP libraries, it is obvious that 7.0 was > missing this feature. As Benjamin mentioned, you could see that all > libraries that migrated from 5.x just skipped 7.0 and went straight to > support 7.1. I did the same for all my packages because of this reason. I > made a misstake to assume that everybody had the same “world of maintaining > PHP libraries” as I do. > > My understanding from all interactions on this list is that posters saying > that something is important is (almost?) never sufficient. Instead it is > incumbent upon RFC authors and RFC supporters to go the extra mile and make > a strong case for why something is needed. And thus far, I have not seen > any actual cases where it is needed, I have only heard assertions. > > Note I am not against this. I tend to prefer more functionality in a > language, not less. So by asking you to give examples I am actually trying > to help you make your case. And it is puzzling to me why you are pushing > back so hard when I ask for use-cases. > > > 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. The reason for a > package to drop PHP 7 support is to be able to use the cool features in PHP > 8. This will require a major release (something all maintainer should do > sparsely). Why would I do a new major release if I cannot properly define > my API (interfaces)? I rather wait to next PHP version where I can express > my API and do my major release then. > > That is not a real-world example of why nullable intersection types are > really needed. That is an assertion about library maintainer's concerns who > want nullable intersection types. > > It is not code nor does it have anything mention of how any use-cases > where nullable intersection types would be applied. > > > Sorry if I sounded (or keep sounding negative). I appriciate you and > everybody else participate in this discussion. We are all trying to make > PHP better and we are all trying to move this RFC forward. > > Then give some actual examples instead of just repeating assertions that > this is needed and if you don't get it you believe it will make your life > more difficult as a library maintainer. > > There are tens of things that make my life difficult every day I program > in PHP, but this list doesn't care about my own or any of our difficulties, > it cares about real-world use-cases that would provide reason why a feature > needs to be added to PHP. > > -Mike > > P.S. Also, what Deleu said. > >
