Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128188
Precedence: bulk
MIME-Version: 1.0
References: <ClHWqZ8xQp5NMLvOxMZ80CqdIr0QVhrCzJmDZyw0h7Z4CtK3DG8fW3dKbf4fu-WJRxvqBY9S_W29um3mHEaGJ9ee1epItOizujB3CpbNKfA=@gpb.moe>
 <CAOWwgpm7QrZxVjdMSSWLXu2XKqCz8fTKOBX07Wj3Kt4dx=vwWg@mail.gmail.com> <ss0LFSjaby7LhBgSMYgukZkK_pRNxYb75GpS1jil0bFDJcKdqGO8zmdctF48kKaKVJvmQW7gwxBWarfBfvzSsOvrIn1Cn_gEOswM7hvZVAY=@gpb.moe>
In-Reply-To: <ss0LFSjaby7LhBgSMYgukZkK_pRNxYb75GpS1jil0bFDJcKdqGO8zmdctF48kKaKVJvmQW7gwxBWarfBfvzSsOvrIn1Cn_gEOswM7hvZVAY=@gpb.moe>
Date: Wed, 23 Jul 2025 13:30:26 +0200
Message-ID: <CAOWwgp==eG93BZ4pSatviPj7_GXE7u6A7Fe=P27k-PHF6iat0w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Warnings for PHP 8.5
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b899a8063a97097b"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000b899a8063a97097b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le ven. 18 juil. 2025 =C3=A0 14:54, Gina P. Banyard <internals@gpb.moe> a =
=C3=A9crit :

> On Tuesday, 15 July 2025 at 18:16, Nicolas Grekas <
> nicolas.grekas+php@gmail.com> wrote:
>
> Hi Gina,
>
> Le lun. 14 juil. 2025 =C3=A0 18:22, Gina P. Banyard <internals@gpb.moe> a
> =C3=A9crit :
>
>> Hello internals,
>>
>> Similar to the mass deprecation RFC, I would like to propose the additio=
n
>> 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 quickl=
y
> about it by an error handler that promotes warnings is the behaviour I wa=
nt.
>

Then obviously this argument doesn't apply to destructuring non-array
values.
This makes me doubtful about the others. A deprecation would be more
appropriate to me.


> 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] =3D $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] =3D $array[$key] ?? [null, null])
>
> makes more sense, especially as this allows you to choice different
> defaults for $a and $b.
>

That's broken, the "if" will always be truthy using this style.
There's nothing wrong with the current code. It doesn't need to be
deprecated.
I'd say the same when false is returned BTW.
For other values, I'm not aware of any use cases so might be fine
deprecating.

Nicolas

--000000000000b899a8063a97097b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 18=
 juil. 2025 =C3=A0=C2=A014:54, Gina P. Banyard &lt;internals@gpb.moe&gt; a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><div>On Tuesda=
y, 15 July 2025 at 18:16, Nicolas Grekas &lt;<a href=3D"mailto:nicolas.grek=
as%2Bphp@gmail.com" target=3D"_blank">nicolas.grekas+php@gmail.com</a>&gt; =
wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div dir=3D"ltr">Hi Gina,</div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le lun. 14 juil. 202=
5 =C3=A0 18:22, Gina P. Banyard &lt;internals@gpb.moe&gt; a =C3=A9crit :<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello internals,<b=
r>
<br>
Similar to the mass deprecation RFC, I would like to propose the addition o=
f a few warnings in certain situations:<br>
<a href=3D"https://wiki.php.net/rfc/warnings-php-8-5" rel=3D"noreferrer nof=
ollow noopener" target=3D"_blank">https://wiki.php.net/rfc/warnings-php-8-5=
</a><br>
<br>
I am expecting these 4 sub-proposals to be mostly uncontroversial,<br>
other than possibly, the &quot;Using offsets on non-container values in iss=
et()/empty()&quot; one.<br>
<br>
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.</blockquote><div><br=
></div><div>Why warnings and not deprecations if the plan is to Error on PH=
P 9?</div><div>As you might know, it&#39;s very common to turn warnings int=
o exceptions in userland so this will break apps for sure. Deprecations don=
&#39;t if properly handled. Please trigger deprecations instead.</div></div=
></div></blockquote><div><br></div><div>Because those point to bugs, rather=
 than usage of a valid feature.</div><div>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.</div></div></div></blockquote><=
div><br></div><div>Then obviously this argument doesn&#39;t apply to=C2=A0d=
estructuring non-array values.</div><div>This makes me doubtful about the o=
thers. A deprecation would be more appropriate to me.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-famil=
y:Arial,sans-serif;font-size:14px"><div><blockquote type=3D"cite"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div>About destructuring non-array valu=
es, null is a very common case that allows writing nice readable code.</div=
><div>Here is a dummy example:</div><div>if ([$a, $b] =3D $array[$key] ?? n=
ull) { /*...*/ }</div><div><br></div><div>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 miss=
ed any other rationale.</div></div></div></blockquote><div><br></div><div>I=
f you want to provide default values, then surely:</div><div><br></div><div=
>if ([$a, $b] =3D $array[$key] ?? [null, null])<br></div><div><br></div><di=
v>makes more sense, especially as this allows you to choice different defau=
lts for $a and $b.<span></span></div></div></div></blockquote><div><br></di=
v><div>That&#39;s broken, the &quot;if&quot; will always be truthy using th=
is style.</div><div>There&#39;s nothing wrong with the current code. It doe=
sn&#39;t need to be deprecated.</div><div>I&#39;d say the same when false i=
s returned BTW.</div><div>For other values, I&#39;m not aware of any use ca=
ses so might be fine deprecating.</div><div><br></div><div>Nicolas</div></d=
iv></div>

--000000000000b899a8063a97097b--