On Thu, Feb 13, 2025, at 8:16 AM, Tim Düsterhus wrote:
> 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
Just spitballing:
"Return value of foo() is not used, on foo.php line 5: <user text here>"
Fiddle with the wording as needed, but by having a colon and then the user text, it makes it clear
it's a separate statement, and can be as flexible as a statement in your chosen language wants
to be.
--Larry Garfield