Re: [RFC] Display Function Arguments in Errors
| From: | Calvin Buckley | Date: | Thu, 12 Mar 2026 15:53:51 +0000 |
| Subject: | Re: [RFC] Display Function Arguments in Errors | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-130295@lists.php.net to get a copy of this message | ||
On Mar 11, 2026, at 3:35 PM, Tim Düsterhus <tim@bastelstu.be> wrote:
>
> Hi
>
> On 3/11/26 16:55, Calvin Buckley wrote:
>> Based on the feedback I had from my proposal for function arguments in
>> errors last week, I'd like to introduce an RFC for it. Please let me
>> know what you think and please raise any possible issues.
>> https://wiki.php.net/rfc/display_error_function_args
>
> Thank you for the RFC. I have the following comments:
>
> 1.
>
> I believe there is almost never “No Impact” to the ecosystem. In fact the RFC partly
> acknowledges it in the “Backward Incompatible Changes” section. Even if the corresponding
> sub-vote to default to 1 doesn't pass, code needs to be prepared for someone to set it to 1
> themselves. This includes off-the-shelf software (such as WordPress, or Drupal, or whatever).
I'm adding this to the ecosystem impact section.
> I have the following two suggestions (that follow pretty naturally, but are nevertheless an
> impact that should be spelled out):
>
> a) Custom error handlers (set_error_handlers()) need to be prepared for the error message
> format to change. Even though we don't make any guarantees about error messages themselves, the
> existing format with “function name first” is reasonably structured for automated parsing (e.g.
> using a regular expression). This also includes error tracking tools that try to group error
> messages by function or similar.
>
> b) System administrators have one more INI setting to deal with and need to make a decision.
> Previous versions of the RFC template had an explicit “INI setting” section, but given it's
> so rare we add new INI settings these days, it has been removed from the template. For the few that
> still add one, properly discussing the consequences still is valuable.
I do recognize that PHP has been trending towards fewer knobs;
unfortunately, I don't see a better way other than adding a new
knob.
> 2.
>
> As for the naming of the bikeshed, I suggest
error_ignore_args
> for consistency with zend.exception_ignore_args.
I'm not attached to the name; if others think this sounds good, I'll
adjust the RFC and PR.
> 3.
>
> For the voting options: You need to define a tie-breaker for the secondary votes.
I might be a little dense here; I see tie-breakers mentioned in
feature-proposals, but I don't see any guidance on how to include them
in an RFC. The other RFCs I've been skimming don't seem to mention them
either.
> Best regards
> Tim Düsterhus