Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126389
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 13 Feb 2025 15:16:52 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: RFC: Marking return values as important
 (#[\NoDiscard])
In-Reply-To: <3d188924-33cf-4c3b-b7ff-3bd29232f16a@app.fastmail.com>
References: <a995ac24905030e168e7f6006b996cd5@bastelstu.be>
 <CAMzRQTcTrZR2=vnjvVZRt=fEJpiBci9HN36BQAwG8+FK60Gc1A@mail.gmail.com>
 <3d188924-33cf-4c3b-b7ff-3bd29232f16a@app.fastmail.com>
Message-ID: <386df71fdd6818ddd54c771a889b7d5d@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-02-12 22:31, schrieb Larry Garfield:
> I'm still undecided on the RFC overall, but one thing that is 
> problematic is the phrasing of the messages.  Currently, the messages 
> in the attribute are fragments of an English sentence, seemingly 
> designed to fit grammatically with a sentence fragment that is coded 
> into the engine somewhere but not readily available to developers.

Yes, the implementation of the error message very closely matches that 
of #[\Deprecated] (except that there is no `since` bit to insert).

> From my phrasing I think you can guess my opinion of that.
> 
> That is impossible to document cleanly for English speakers.  It will 
> not translate at all for anyone who is writing in a non-English 
> language (which people do).  People are going to get it wrong more than 
> they get it right, in any language.
> 
> Instead, the wording should be structured to be a complete sentence, 
> and the built-in message updated to make that logical.  That gives the 
> developer much more freedom to write a meaningful, 
> contextually-relevant message in the language of their choice.

We're open to adjusting that. Do you have any suggestions? The 
implementation of #[\Deprecated] works like it does, because PHP itself 
already doesn't end the error messages with a `.`, as it appends `in 
file.php on line 42`. This makes it inconvenient to have more than one 
sentence in an error message, which is why we're struggling with coming 
up with something better.

Best regards
Tim Düsterhus