Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126236
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [PHP-DEV] RFC: Marking return values as important (#[\NoDiscard])
Date: Wed, 29 Jan 2025 23:48:03 +0100
References: <a995ac24905030e168e7f6006b996cd5@bastelstu.be>
 <a3d14e31-53eb-4a04-8fb2-01f58809fec1@app.fastmail.com>
 <3f170549-cfd6-441e-b892-cf51d726dbe8@bastelstu.be>
 <3b4d9be8-9255-44ab-95c5-ea3045212cf4@app.fastmail.com>
To: php internals <internals@lists.php.net>
In-Reply-To: <3b4d9be8-9255-44ab-95c5-ea3045212cf4@app.fastmail.com>
Message-ID: <B698F6D0-7EB8-49B8-9638-072B8BE40AC1@cschneid.com>
From: cschneid@cschneid.com (Christian Schneider)

Am 29.01.2025 um 21:16 schrieb Rob Landers <rob@bottled.codes>:
> On Wed, Jan 29, 2025, at 20:50, Tim D=C3=BCsterhus wrote:
>> The `(void)` cast makes the intent of not being interested in the =
return=20
>> value clear. In C casting to `(void)` is an established pattern of=20
>> "using" a value that the compiler would otherwise consider unused.=20
>=20
> I understand what you are saying, but I can also just remove the =
warning via:
>=20
> $_ =3D outer();
>=20
> Which, to me, is clearer on the intent than (void)outer(); It also =
happens to make the diffs more natural looking when and if the return =
value gets used during a code review. I'll also note that having (void) =
doesn't preclude me from using $_ either.

I think the (void) cast is familiar for people from C or the like, the =
only caveat is that it is not backward compatible, i.e. code using it =
won't work on older versions of PHP so migrating to it is not seamless, =
so it probably should not be used for a while in public libraries / =
packages.

I guess another option would be to define a
	function nop($_) {}
and then use
	nop(outer());
but my question is whether $_ =3D outer() and nop(outer()) will be =
guaranteed to not being optimized in a way which causes the warning to =
reappear. I don't know much about the optimizations being done but this =
could be an issue in the future, no?

Regards,
- Chris