Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127826
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 1 Jul 2025 23:41:45 +0900
Message-ID: <CAHR_AjSDq878GKVXcQk+UNFcTwFEEA_s0VgP=xZWn6vtviXy-w@mail.gmail.com>
Subject: [PHP-DEV] Expanding the scope of the #[NoDiscard] attribute
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000685a5a0638df2580"
From: tadsan@zonu.me (Kenta Usami)

--000000000000685a5a0638df2580
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi internals,

I'm writing to start a discussion about expanding the use of the newly
accepted #[NoDiscard] attribute.
I believe this attribute is a fantastic addition that will help
prevent many subtle bugs, and we can make it even more effective by
applying it to a broader set of core functions.

My initial thoughts for strong candidates are:

- All is_* prefixed functions
- The password_*() functions
- Most string functions: Many string functions like strlen(),
  substr(), trim(), and str_replace() are also clear candidates.
  We would naturally exclude functions with output side effects, such
  as the printf() family.
- Mathematical functions
- Pure array_*() functions: Functions that don't accept callbacks,
  such as array_keys(), array_values(), array_reverse(), and
  array_unique(), are also strong candidates. Their return value is
  their only result.

On the other hand, applying this to all array_* functions is more
debatable. For example, functions like array_map() and array_filter()
can be used with callbacks that have side effects (impure
functions). In such cases, the return value might be intentionally
discarded. Applying #[NoDiscard] to them could lead to false positives
for legitimate code.

This nuance extends to other areas, like many filesystem functions
which require case-by-case evaluation. A tricky example is
file_get_contents(). At first glance, it seems like an obvious
candidate. However, despite its name, it can be used to send external
HTTP requests where the primary goal might be the side effect of the
request itself (like a webhook ping), and the returned content is
intentionally ignored. Adding #[NoDiscard] here could create issues
for existing code. This might be a type of change best reserved for a
major version like PHP 9.0 to avoid backward compatibility breaks.

Finally, I would love to hear the community's thoughts on the
timeline. Should we aim to add these attributes for PHP 8.5, or should
we introduce potentially breaking changes like these more gradually,
perhaps leading up to PHP 9.0?

Thanks,

Kenta

--=20
=E3=83=BE(=E3=80=83=EF=BC=9E=EF=BC=9C)=EF=BE=89=EF=BE=9E=E2=98=86 Kenta Usa=
mi (=E5=AE=87=E4=BD=90=E7=BE=8E=E5=81=A5=E5=A4=AA)
github.com/zonuexe ; https://tadsan.github.io/

--000000000000685a5a0638df2580
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi internals,<br><br>I&#39;m writing to start a discu=
ssion about expanding the use of the newly<br>accepted #[NoDiscard] attribu=
te.<br>I believe this attribute is a fantastic addition that will help<br>p=
revent many subtle bugs, and we can make it even more effective by<br>apply=
ing it to a broader set of core functions.<br><br>My initial thoughts for s=
trong candidates are:<br><br>- All is_* prefixed functions<br>- The passwor=
d_*() functions<br>- Most string functions: Many string functions like strl=
en(),<br>=C2=A0 substr(), trim(), and str_replace() are also clear candidat=
es.<br>=C2=A0 We would naturally exclude functions with output side effects=
, such<br>=C2=A0 as the printf() family.<br>- Mathematical functions<br>- P=
ure array_*() functions: Functions that don&#39;t accept callbacks,<br>=C2=
=A0 such as array_keys(), array_values(), array_reverse(), and<br>=C2=A0 ar=
ray_unique(), are also strong candidates. Their return value is<br>=C2=A0 t=
heir only result.<br><br>On the other hand, applying this to all array_* fu=
nctions is more<br>debatable. For example, functions like array_map() and a=
rray_filter()<br>can be used with callbacks that have side effects (impure<=
br>functions). In such cases, the return value might be intentionally<br>di=
scarded. Applying #[NoDiscard] to them could lead to false positives<br>for=
 legitimate code.<br><br>This nuance extends to other areas, like many file=
system functions<br>which require case-by-case evaluation. A tricky example=
 is<br>file_get_contents(). At first glance, it seems like an obvious<br>ca=
ndidate. However, despite its name, it can be used to send external<br>HTTP=
 requests where the primary goal might be the side effect of the<br>request=
 itself (like a webhook ping), and the returned content is<br>intentionally=
 ignored. Adding #[NoDiscard] here could create issues<br>for existing code=
. This might be a type of change best reserved for a<br>major version like =
PHP 9.0 to avoid backward compatibility breaks.<br><br>Finally, I would lov=
e to hear the community&#39;s thoughts on the<br>timeline. Should we aim to=
 add these attributes for PHP 8.5, or should<br>we introduce potentially br=
eaking changes like these more gradually,<br>perhaps leading up to PHP 9.0?=
<br><br>Thanks,<br><br>Kenta</div><div><br></div><span class=3D"gmail_signa=
ture_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature" data-=
smartmail=3D"gmail_signature"><div dir=3D"ltr">=E3=83=BE(=E3=80=83=EF=BC=9E=
=EF=BC=9C)=EF=BE=89=EF=BE=9E=E2=98=86 Kenta Usami (<font face=3D"ms pmincho=
, serif">=E5=AE=87=E4=BD=90=E7=BE=8E=E5=81=A5=E5=A4=AA</font>)<br><div><a h=
ref=3D"http://github.com/zonuexe" target=3D"_blank">github.com/zonuexe</a> =
; <a href=3D"https://tadsan.github.io/" target=3D"_blank">https://tadsan.gi=
thub.io/</a></div></div></div></div>

--000000000000685a5a0638df2580--