Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126569
Precedence: bulk
MIME-Version: 1.0
References: <55b798d4-dcd7-4d81-852b-b78294cdc39d@email.android.com>
 <1a980468-c5f3-485b-9e8b-8c97d6ac4802@bastelstu.be> <CAAwdEzD7x=HccDQ9ckz+v=1nBm9NCY1i4GPizLoZsUZQ7FDFEA@mail.gmail.com>
 <e2f31f38-1f8f-407f-8552-824a8f171d66@bastelstu.be>
In-Reply-To: <e2f31f38-1f8f-407f-8552-824a8f171d66@bastelstu.be>
Date: Tue, 4 Mar 2025 23:36:35 +0100
Message-ID: <CAAwdEzD=Sq7Zv=+QzoB0zq7mdTUqqsdKm2q-NyTe6XHes+z0Gg@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: RFC: Marking return values as important (#[\NoDiscard])
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: "Marc B." <marc@mabe.berlin>, Volker Dusch <volker@tideways-gmbh.com>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a9b950062f8be8bf"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000a9b950062f8be8bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 4, 2025, 23:22 Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:

>
> > Or identify that the function has the NoDiscard attribute and based on
> that
> > do not optimize away the variable?
>
> First things first: It's not a super important optimization to have, the
> assignment to a variable is one of the cheaper operations - and given
> that OPcache needs to know about the function it's also pretty limited
> in application. Of course you can also always just remove the assignment
> yourself (or ask your favorite IDE or static analyzer to point it out
> for you).
>
> That said: Checking for the attribute and performing the optimization is
> likely possible, though likely of limited cost/benefit. In any case that
> would be an implementation detail that does not change observable
> behavior. The RFC defines that `(void)` or alternatively `$_` will be
> the solution that guarantees that the warning will be suppressed (which
> will then also be part of the documentation), how exactly that will work
> internally is something that can and will change when refactoring and
> evolving the engine and OPcache.
>
> Thank you for explaining.

My motivation for asking is because I believe that special casing $_
variable might not be a desirable solution, and I personally find it worse
than (void) casting.
And so, people might vote "No" for the first vote because they are not
happy with either results of the second option. And maybe we can find a
technical solution that doesn't require a behavior/documentation change if
second vote fails.

I agree that this optimization is not really important, so finding a way to
avoid it would be nice.

--
Alex

--000000000000a9b950062f8be8bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 4, 2025, 23:22 Tim D=
=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.be</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; Or identify that the function has the NoDiscard attribute and based on=
 that<br>
&gt; do not optimize away the variable?<br>
<br>
First things first: It&#39;s not a super important optimization to have, th=
e <br>
assignment to a variable is one of the cheaper operations - and given <br>
that OPcache needs to know about the function it&#39;s also pretty limited =
<br>
in application. Of course you can also always just remove the assignment <b=
r>
yourself (or ask your favorite IDE or static analyzer to point it out <br>
for you).<br>
<br>
That said: Checking for the attribute and performing the optimization is <b=
r>
likely possible, though likely of limited cost/benefit. In any case that <b=
r>
would be an implementation detail that does not change observable <br>
behavior. The RFC defines that `(void)` or alternatively `$_` will be <br>
the solution that guarantees that the warning will be suppressed (which <br=
>
will then also be part of the documentation), how exactly that will work <b=
r>
internally is something that can and will change when refactoring and <br>
evolving the engine and OPcache.<br><br></blockquote></div></div><div dir=
=3D"auto">Thank you for explaining.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">My motivation for asking is because I believe that special casi=
ng $_ variable might not be a desirable solution, and I personally find it =
worse than (void) casting.</div><div dir=3D"auto">And so, people might vote=
 &quot;No&quot; for the first vote because they are not happy with either r=
esults of the second option. And maybe we can find a technical solution tha=
t doesn&#39;t require a behavior/documentation change if second vote fails.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">I agree that this optim=
ization is not really important, so finding a way to avoid it would be nice=
.</div><div dir=3D"auto"><br></div><div dir=3D"auto">--</div><div dir=3D"au=
to">Alex</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_qu=
ote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000a9b950062f8be8bf--