On Mar 11, 2026, at 3:35 PM, Tim Düsterhus <[email protected]> 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
