> On Wed, 28 Jul 2021 at 08:29, Nicolas Grekas <nicolas.gre...@gmail.com> > wrote: > > Nullability is a special beast in PHP. We have a range of operators > > dedicated to it. That's also why I think it deserves special care, and > why > > I think it's important to have this discussion before 8.1 is out. > > Why does this change need to be done now, rather than wait for 8.2? > > I can't see a clear reason in the RFC and saying 'nullability is > special' doesn't seem a clear reason either. If you think you'll only > be able to use intersection types when they can be union'ed with null, > then ... just wait until they are? >
I will wait if I don't have the choice, but as many others reported, the experience with 7.0 missing nullability was a pain. We can learn from past mistakes. In my opinion, we can do better than the "wait for 8.2" stance I'm hearing around and make intersection nullable - like every other type in PHP - right now while we first release it. More generally, I'm not in favor of shipping partial features based on hypothetical future improvements. We don't know the future. Eg type aliasing or generics are vaporware right now. One or both of them might never happen, for whatever reason. > Andreas Leathley wrote: > > Having one clear RFC voting option (with no > > secondary syntax voting option) also seems the most honest, as if > > somebody agrees that nullability would be useful but would only accept > > one syntax choice, that seems impossible to represent, necessitating a > > no vote on the whole RFC. > > I strongly agree with this. > > Having a situation where people will want to change their primary > vote, based on which option in a secondary vote is winning is a "not > good" situation. > > Having syntax for a type system be chosen by a popularity contest, > where many of the voters are not aware of the implications of the > choices is also not good. > I find it quite dismissing to refer to "voters" as a group that decides by "popularity contest" or that is "not aware of the implications of the choices". I do trust the voting process and I do think that the discussions we're having here on php-internals and related media are appropriate means to raise voters' awareness of the topics at a glance (I also think the voting process might be improved, but there's already a separate thread about that.) Instead of fearing others, let's discuss things and ensure we raised all points so that ppl can make an informed decision. After this discussion, I hope ppl will vote according to what they think is best for PHP as a whole, all questions included, and independently from the rest. That'd be the most honest thing to do IMHO, and the best for PHP (on this RFC or on any other.) RFC authors should be trying to pass an RFC they are sure is the right > choice, not leaving important decisions up in the air. > Because nobody raised any potential blocker with any of the proposed syntax, I'm confident that all voting options have equal future-proofness. The remaining is a matter of coding style preference. While as the author of the RFC I do have a preference for the "?" nullability flag, others have strong and different opinions about it. Since the primary motivation for this PR is to provide nullability for intersection types, I'll be fine with any syntax that is consensual eventually. > Larry Garfield wrote: > > Some other mechanism such as the sometimes discussed type > > aliases provides an alternate way to solve this problem. > > This is an important point and why trying to push changes to the type > system through after feature freeze is a bad idea. > > The example in the RFC uses single letter class names; in my > experience most classes have quite a few more letters in them than > that. Trying to use intersection types with realistic class names > leads to code like this, for a custom cache definition*. > > function foo(Get|GetOrDefault|Set|SetWithTTL|GetOrGenerate|Clear $cache) { > ... > } > > Which is pretty unreadable. I don't think I'll be using intersection > types much until PHP has the capability to compose types. e.g. > something similar to this: > > type SimpleCache = Get|GetOrDefault|Set|SetWithTTL|GetOrGenerate|Clear; > > function foo(SimpleCache $cache) { > ... > } > > At which point the need for being able to include nullability in the > intersection type goes away. You can instead use the existing ability > to indicate a type can be null: > > function foo(?SimpleCache $cache) { > ... > } > That's an excellent argument in favor of using "?" actually (syntax consistency and readability), thanks for pointing it out. I'd go as far as saying that type aliases should forbid making "null" part of them. That way, nullability would always be explicit in the local type, with an easy-to-spot nullability flag. So yeah....I agree that widespread adoption of intersection types > might not happen in 8.1 but that's fine, and better than possibly > implementing the wrong thing after feature freeze. > We're having this discussion to be sure that "wrong" won't happen, while the good will. And based on what was raised so far, I see only the good coming. Cheers, Nicolas