> 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.
