Repository navigation
Consider deferring the "is"/"let" identifier deprecation to PHP 8.7 #23990
Description
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.
Activity
Girgias commentedon Sep 29, 2026
It was merged prior to RC1, RC2 got tagged shortly after RC1 do to a mistake in the packaging.
iluuu1994 commentedon Sep 29, 2026
@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
Isdeprecation staying in 8.6. But it's ultimately Gina's call, given she proposed it.bwoebi commentedon Sep 29, 2026
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 commentedon Sep 29, 2026
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 commentedon Sep 29, 2026
I had spotted
guzzle/promisesin 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:
bwoebi commentedon Sep 29, 2026
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 commentedon Sep 29, 2026
You'd have to
error_reporting(0);before importing the file, no? This is a compile-time warning. For-ryou'd need to use-d.mbeccati commentedon Sep 29, 2026
@iluuu1994 good luck with autoloading ;-)
iluuu1994 commentedon Sep 29, 2026
@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.
ndossche commentedon Oct 1, 2026
Can use
@class_alias(...)as a workaround with a hacked-on autoloader I suppose.iluuu1994 commentedon Oct 1, 2026
@GrahamCampbell Can you confirm whether any of those options work for you?
andypost commentedon Oct 1, 2026
Checked it as Drupal now needs solution too and only Masking during load works. Wrapping the include in
error_reporting(... & ~E_DEPRECATED)(or@include) stops the declaration warning. A cached file stays silent too.GrahamCampbell commentedon Oct 2, 2026
I’d honestly object to the depreciation entirely.
Girgias commentedon Oct 2, 2026
Considering that if PHP gets pattern matching you will need to change the name of the class, as it will then be a hard compile error.
The whole point of this deprecation is to give people time to find a way to migrate away from that name.
GitHub issues are not the way to revert previous decisions, an RFC and the internal mailing list is.