Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130497
Precedence: list
MIME-Version: 1.0
Date: Mon, 30 Mar 2026 17:24:33 +0200
To: Calvin Buckley <calvin@cmpct.info>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Display Function Arguments in Errors
In-Reply-To: <0598E8E2-F795-45E4-9177-0CA1B1808008@cmpct.info>
References: <939CFA28-A6FF-433F-85A0-B83345CEF4A6@cmpct.info>
 <0598E8E2-F795-45E4-9177-0CA1B1808008@cmpct.info>
Message-ID: <d9e0446c32d1b551024bd7d4b0b1d05c@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 2026-03-30 16:40, schrieb Calvin Buckley:
> If I don't hear any additional feedback, I think I'll open this for
> voting at the end of the week.

I've looked once more into my “naming remark” and realized that the 
`display_` prefix might actually be misleading (instead of “just” 
inconsistent) when compared to `display_errors` or 
`display_startup_errors`, because `display_error_function_args` does not 
control whether the arguments are *displayed*. It also controls whether 
or not the arguments are visible to a registered error_handler, which is 
quite different from just suppressing them from public display as done 
by `display_errors`.

My suggestion of `error_ignore_args` thus still stands and I would 
likely vote against the RFC with the current naming (despite being in 
favor of the feature itself).

Best regards
Tim Düsterhus