Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126404
Date: Fri, 14 Feb 2025 11:46:10 +0000 (GMT)
To: Volker Dusch <volker@tideways-gmbh.com>
cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
    php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: RFC: Marking return values as important
 (#[\NoDiscard])
In-Reply-To: <CAMzRQTcTrZR2=vnjvVZRt=fEJpiBci9HN36BQAwG8+FK60Gc1A@mail.gmail.com>
Message-ID: <83f33b28-b630-0afe-2c7d-2f899cd722ca@php.net>
References: <a995ac24905030e168e7f6006b996cd5@bastelstu.be> <CAMzRQTcTrZR2=vnjvVZRt=fEJpiBci9HN36BQAwG8+FK60Gc1A@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1003179381-1739533570=:13815"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1003179381-1739533570=:13815
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 12 Feb 2025, Volker Dusch wrote:

> On Wed, Jan 29, 2025 at 4:12=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu=
=2Ebe> wrote:
>=20
> > Volker and I would like to start discussion on our RFC to allow "Markin=
g
> > return values as important (#[\NoDiscard])".
> >
> > Please find the following resources for your reference:
> >
> > - RFC: https://wiki.php.net/rfc/marking_return_value_as_important
> > - Implementation: https://github.com/php/php-src/pull/17599
> Hello everyone,
>=20
> it's been two weeks, but given the feedback we received, we don't feel=20
> the discussion didn't reach a conclusive resolution yet.
>=20
> So we wanted to solicit additional opinions. In an attempt to=20
> summarize the discussion, how we see it, there are two main points of=20
> contention we'd like to discuss further.
>=20
> a) Intentionally discarding the return value
>=20
> The `(void)flock($fp);` syntax was the main thing discussed on the list.
> With `$_ =3D flock($fp);` as the most suggested alternative.
>=20
> The issue with using `$_` as it currently stands, is that the unused=20
> variable would be cleaned up by OPcache. Should we instead have a=20
> special case in OPcache ensuring it does not apply its optimization to=20
> a variable if it's named `$_` instead? The semantic difference would=20
> be that $_ would keep returned values (and objects) alive and in=20
> memory, whereas (void) would discard them immediately. Leading to=20
> different times when, for example, destructors would be called.
>
> The consequence of this would be that 3rd party tools like IDEs and=20
> Static and Dynamic Code Analyzers would also have to build that=20
> special case in to not produce "unused variable" warnings.
>=20
> We're also happy to change the secondary vote to "(void) vs $_" as we=20
> feel there needs to be a way to discard the return value consistently=20
> for this to be a complete and usable feature.

I would not be in favour of special casing this, and henceforth the=20
(void) cast makes more sense to me. Mostly, because the special casing=20
has to be done in many places, and in many tools.
=20
> b) Naming of the attribute
>=20
> Nobody mentioned this on the list, but before opening a vote we'd like=20
> to heard if the attribute name makes sense to you.
>=20
> We've chosen #[NoDiscard] as it's also used in C and C++. See [1] for=20
> the full list of references. If you feel this doesn't fit with PHP, we=20
> welcome other suggestions.

I think it fits, and there is already precedence.

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-1003179381-1739533570=:13815--