Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126237
Feedback-ID: id5114917:Fastmail
Date: Thu, 30 Jan 2025 09:02:21 +0000
To: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC: Marking return values as important (#[\NoDiscard])
User-Agent: K-9 Mail for Android
In-Reply-To: <B698F6D0-7EB8-49B8-9638-072B8BE40AC1@cschneid.com>
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> <B698F6D0-7EB8-49B8-9638-072B8BE40AC1@cschneid.com>
Message-ID: <FC48217C-7934-4957-9DC9-6C5576B78DA8@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 29 January 2025 22:48:03 GMT, Christian Schneider <cschneid@cschneid=2E=
com> wrote:
>I think the (void) cast is familiar for people from C or the like, the on=
ly caveat is that it is not backward compatible, i=2Ee=2E 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=2E

I suspect that a majority of PHP users will probably have had no experienc=
e in C, which is easy to forget on this list where we're working on a C cod=
ebase=2E In C, "void" has various uses in the type system, but in PHP this =
would effectively just be a specific keyword for this case=2E

I think it would be good to explore alternatives - for instance, I think C=
# has a reserved _ variable to assign discarded results to, but may be misr=
emembering=2E


>but my question is whether $_ =3D outer() and nop(outer()) will be guaran=
teed to not being optimized in a way which causes the warning to reappear=
=2E I don't know much about the optimizations being done but this could be =
an issue in the future, no?

I second this concern: having code that you think has suppressed the warni=
ng later be optimized and start warning could be very confusing, and given =
the backwards compatibility issue, users will need something other than "(v=
oid)" which is reliable=2E


My other thought reading the proposal is that if this can be done efficien=
tly, can we use the same approach to warn when a "void" function's return *=
is* used?

Regards,
Rowan Tommins
[IMSoP]