Consider deferring the "is"/"let" identifier deprecation to PHP 8.7

[GrahamCampbell]

The deprecation of is and let as class names from the PHP 8.6 deprecations RFC was implemented in #23709. That PR was merged on 16 September, after feature freeze and during the RC phase. guzzle/promises has a public class GuzzleHttp\Promise\Is, which is used heavily in Guzzle and across the wider ecosystem. Loading it on PHP 8.6 now emits a deprecation notice (guzzle/promises#244).

Renaming a public class is a breaking change for us, so we can only do it in a new major version. Because the deprecation landed this late, maintainers of affected libraries have had almost no time to prepare before 8.6.0 ships, and many users run with deprecations surfaced in tests or logs. I'd like to ask the release managers to consider moving this deprecation to PHP 8.7. That would give downstream projects a normal release cycle to plan the rename.

[Girgias]

It was merged prior to RC1, RC2 got tagged shortly after RC1 do to a mistake in the packaging.

[iluuu1994]

@php/release-managers-86 Can you share your opinion? The deprecation followed the policy. It's conceivable that pattern matching could land for 8.7, but is not guaranteed to. So I wouldn't insist on the Is deprecation staying in 8.6. But it's ultimately Gina's call, given she proposed it.

[bwoebi]

The deprecations have been historically landing late. But that's the process we have: alpha = early release where stuff still gets decided on, beta = release where all major stuff has been decided on, but not implemented yet (i.e. by looking at RFCs you can determine impact now), rc = release with all major stuff having landed (i.e. you can actually verify).

It's not particularly early or late. We have two months of RC, so that users can verify/upgrade stuff.
Whether two months of RC are enough is a policy discussion. But the release process is as intended.

[bwoebi]

Also, you can silence the deprecation. set error_reporting() to remove E_DEPRECATED at the start of the file containing the class declaration, then put it back - only declaration should be deprecated, not usage.

(If this isn't enough, that's something to fix though!)

[mbeccati]

I had spotted guzzle/promises in the impact analysis and voted against this particular deprecation.

It is a fairly prominent package and @bwoebi's suggested workaround doesn't seem to be working:

/opt/php86/bin/php -r 'error_reporting(0); class is {}'

Deprecated: Using "is" as a class name is deprecated since 8.6 in Command line code on line 1

[bwoebi]

In that case, if you cannot work around that deprecation as easily (I mean, you could put it into error_reporting(0); eval(<<<'CODE' ... CODE);, but that's insane.) ... @Girgias Could you either please fix this, or we should indeed punt it to 8.7.

(Yeah, right, I forgot that this was done as a compiler-level deprecation.)

[iluuu1994]

You'd have to error_reporting(0); before importing the file, no? This is a compile-time warning. For -r you'd need to use -d.

[mbeccati]

@iluuu1994 good luck with autoloading ;-)

[iluuu1994]

@mbeccati Should have a simple workaround of moving the class itself into a different file and including it from the autoloaded file. But I'm just a bystander. 😅 I don't have a strong opinion here either way.