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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
