Re: [RFC] [Vote] Deprecate functions with overloaded signatures
| From: | Rowan Tommins | Date: | Tue, 27 Jun 2023 11:33:03 +0000 |
| Subject: | Re: [RFC] [Vote] Deprecate functions with overloaded signatures | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120697@lists.php.net to get a copy of this message | ||
On 27/06/2023 02:25, Theodore Brown wrote:
Currently the following code returns only the array keys that loosely equal null [1]:An alternative solution to this situation is to introduce a new dummy value for such parameters, similar to how JavaScript uses the special "Symbol" type to have keys that can't collide with any userland value. In this context, this could be achieved with a single-value enum, i.e.: enum ArrayKeys { case IncludeAll; } function array_keys(array $array, mixed $filter_value = ArrayKeys::IncludeAll, bool $strict = false): array {} That way, the optional parameter has a real default value, distinct from any value the user might wish to filter by, including null, and full compatibility is maintained with existing code. I don't know whether this is a direction we want to go, but thought I'd throw it out there. Regards, -- Rowan Tommins [IMSoP]array_keys($array, null)If the function is changed to a single signature with $filter_value defaulting to null (with an argument count check to preserve the above functionality), its behavior becomes a lot more surprising/unexpected. If a parameter defaults to null, as a user I don't expect the function to work differently when I explicitly pass the default value.