Re: Re: [RFC] Nullable intersection types

On 11/08/2021 13:09, Nicolas Grekas wrote:

    On 10/08/2021 13:39, Nicolas Grekas wrote:

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.

    Apologies if you already did and I've forgotten, but could you please
    expand on what "pain" you are referring to here?

I personally did not experience that pain because I just skipped 7.0, since it wouldn't allow expressing the nullable return types I had to express in the APIs I maintain.

Sorry, I'm still confused what the "pain" is *other than* feeling obliged to wait until 7.1.

The larger issue is that when used as a type on arguments, adding the nullability flag isn't possible without a BC breaking change.

I can't imagine many people will force a parameter to be non-nullable just to use the shiny new syntax, then re-allow nulls in a subsequent version. More likely, they will leave that parameter un-checked until the full type can be specified. There is also a lot of code out there which is either: * in stand-alone applications, so backwards compatibility has no meaning * in private libraries with a handful of uses, so bringing uses in line is trivial * in public libraries, but marked "private" or "final", or documented as "internal use only", and therefore not subject to compatibility guarantees

But until it's too late, I'm willing to engage in this topic because I think the current state is far from ideal for 8.1.

There are always more features we could add, and there will always be a judgement call of what versions of PHP a code base should support. If it was generally agreed that there was only one right way to implement nullable intersections, and it was a trivial change, then I'd support it as a "quick win"; but that doesn't seem to be the case. Regards, -- Rowan Tommins [IMSoP]