Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115594
MIME-Version: 1.0
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <CAESVnVrCpYCB9VLFvAFbM4gzdBxHcmJQt75cqFcT0wHowMjXYw@mail.gmail.com> <F039E1EA-572D-460A-93B5-CBEAA47780FF@stitcher.io>
In-Reply-To: <F039E1EA-572D-460A-93B5-CBEAA47780FF@stitcher.io>
Date: Tue, 27 Jul 2021 13:10:26 -0700
Message-ID: <CAMrTa2EB8rq16bBO-EQ3YBJJmj_s1VqZLji95JSF=3fbDotXUQ@mail.gmail.com>
To: Brent Roose <brendt@stitcher.io>
Cc: PHP Internals <internals@lists.php.net>, Nicolas Grekas <nicolas.grekas@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d6876705c8207511"
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000d6876705c8207511
Content-Type: text/plain; charset="UTF-8"

> - 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 <brendt@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 <pollita@php.net> wrote:
> >
> > On Fri, Jul 23, 2021 at 4:58 AM Nicolas Grekas <nicolas.grekas@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
>
>

--000000000000d6876705c8207511--