> - PHP 7.0 types were a pain because of non-nullable types, the feature only became really useful as of PHP 7.1
See, this keeps being said, but as another userland developer it's extremely confusing. The types in 7.0 were very useful, and I personally didn't notice at all that they were missing because I used something like function(int $var = null), which is how nulls had been marked before PHP 7. In fact, when 7.1 was released, none of the signatures changed in my code, they were just updated to a different syntax. > - I share many people's opinion that this falls in the category of oversight I don't see how, when the intersection types RFC was: - Named "pure intersection types", which to me can only mean that the authors were both aware that there were other integrations which may be suggested and were excluding them from scope. - It contained an explicit mention of this issue: > This means it would *not* be possible to mix intersection and union types together such as A&B|C, this is left as a future scope. I also am not seeing that opinion from "many people" in this thread. Are you referring to other people off-list who are discussing this? Jordan On Tue, Jul 27, 2021 at 6:32 AM Brent Roose <bre...@stitcher.io> wrote: > Hi all > > From a userland developer point of view: > > - PHP 7.0 types were a pain because of non-nullable types, the feature > only became really useful as of PHP 7.1 > - I share many people's opinion that this falls in the category of > oversight > - I think (A&B)|null is the only sensible way to go > > Sidenote: weren't there any prior cases where an RFC was accepted only to > have found out an oversight which resulted in that RFC to be postponed to > the next release? > > Kind regards > Brent > > > On 26 Jul 2021, at 16:14, Sara Golemon <poll...@php.net> wrote: > > > > On Fri, Jul 23, 2021 at 4:58 AM Nicolas Grekas <nicolas.gre...@gmail.com > > > > wrote: > > > >> https://wiki.php.net/rfc/nullable_intersection_types > >> > >> > > I've commented on the PR and in R11 a bit already, but I'd like to state > my > > position here for the record. I do see the value in having nullability, > > but I can't disagree enough with the `?X&Y` syntax no matter how > > technically right the argument about operator precedence is. Even > ignoring > > that literally nobody carries around a complete operator precedence table > > in their head, we simply can't predict how making this decision now will > > impact future plans for combined intersection/union types. The same > > argument honestly goes for every other syntax proposed, including > > `(X&Y)|null` which is also prone to making things worse. > > > > Nullable intersection types *IS* an implementation of combined > > intersection/union types, even if a narrow one. Those have not been > planned > > out or approved, and they're too broad to sneak in post feature freeze. > > Period. Let's take the coming months to flesh out the edge cases on > > combined types. Let's maybe even look into type aliasing, which may have > > the side effect of making combined types more readable (or maybe less, > who > > knows!). > > > > Most importantly, let's accept the fact that PHP's release cycle is only > 12 > > months and we had pandemics that lasted longer than that. Next year is > > right around the corner. > > > > TL;DR - I've decided my vote. > > > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
