Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115684
MIME-Version: 1.0
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <CAOWwgpne5MEBxdvz=Q_zmRf=1abtQstMfpLXW4gbfp4+dRokfA@mail.gmail.com> <CA+kxMuQHz5U7D2E8gRyxxAfToJM6zc721qxLFcZFuTuiarVy3w@mail.gmail.com>
In-Reply-To: <CA+kxMuQHz5U7D2E8gRyxxAfToJM6zc721qxLFcZFuTuiarVy3w@mail.gmail.com>
Date: Tue, 10 Aug 2021 14:39:46 +0200
Message-ID: <CAOWwgpkT2fLEEUgp40UrSMYmtPyoT2OAC_QUX4QDS5cXQAsBog@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bc14f305c933ccc8"
Subject: Re: [PHP-DEV] Re: [RFC] Nullable intersection types
From: nicolas.grekas@gmail.com (Nicolas Grekas)

--000000000000bc14f305c933ccc8
Content-Type: text/plain; charset="UTF-8"

> On Wed, 28 Jul 2021 at 08:29, Nicolas Grekas <nicolas.grekas@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

--000000000000bc14f305c933ccc8--