On Tuesday, 15 July 2025 at 18:16, Nicolas Grekas <nicolas.grekas+...@gmail.com> wrote:
> Hi Gina, > > Le lun. 14 juil. 2025 à 18:22, Gina P. Banyard <intern...@gpb.moe> a écrit : > >> Hello internals, >> >> Similar to the mass deprecation RFC, I would like to propose the addition of >> a few warnings in certain situations: >> https://wiki.php.net/rfc/warnings-php-8-5 >> >> I am expecting these 4 sub-proposals to be mostly uncontroversial, >> other than possibly, the "Using offsets on non-container values in >> isset()/empty()" one. >> >> As this is intended to land in PHP 8.5 the discussion will last 2 weeks and >> voting will commence on Monday the 28th of July 2025. > > Why warnings and not deprecations if the plan is to Error on PHP 9? > As you might know, it's very common to turn warnings into exceptions in > userland so this will break apps for sure. Deprecations don't if properly > handled. Please trigger deprecations instead. Because those point to bugs, rather than usage of a valid feature. As such a warning is appropriate, and people being made aware more quickly about it by an error handler that promotes warnings is the behaviour I want. > About destructuring non-array values, null is a very common case that allows > writing nice readable code. > Here is a dummy example: > if ([$a, $b] = $array[$key] ?? null) { /*...*/ } > > Turning this into a warning will have a significant impact for sure. Even a > deprecation would just make the language a bit less pleasant to use without > any real benefit, unless I missed any other rationale. If you want to provide default values, then surely: if ([$a, $b] = $array[$key] ?? [null, null]) makes more sense, especially as this allows you to choice different defaults for $a and $b. Best regards, Gina P. Banyard
