Re: [RFC] Display Function Arguments in Errors

From: 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

« previous php.internals (#130295) next »