On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote: > > On Jun 26, 2023, at 08:36, Máté Kocsis <kocsismat...@gmail.com> wrote: > > > > Hi Everyone, > > > > As previously announced on the list, I have just started the vote about the > > "Deprecate functions with overloaded signatures". > > > > Link to the RFC: > > https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures > > Link to the discussion thread: https://externals.io/message/120146 > > > > The vote is open until 2023-07-10 16:00:00 UTC. > > > > Regard, > > Máté > > > Clarifying my “no” votes… > > I voted “no” on `array_keys()` because I do not see these as two different > function signatures. To me, the single signature should look like this: > > function array_keys(array $array, ?mixed $filter_value = null, bool > $strict = false): array {} > > I voted “no” on `IntlCalendar::set()` because it seems to me that `setDate()` > and `setDateTime()` could share the same signature if `$hour`, `$minute`, and > `$second` all default to zero, like this: > > public function setDate(int $year, int $month, int $dayOfMonth, int $hour > = 0, int $minute = 0, int $second = 0): void {} > > In the same way, with `IntlGregorianCalendar::__construct()`, > `createFromDate()` and `createFromDateTime()` could be combined as: > > public static function createFromDate(int $year, int $month, int > $dayOfMonth, int $hour = 0, int $minute = 0, int $second = 0): void {}
So commonality here is that these are all arity overloads. I think there's three different kinds of overloads in involved in the RFC: 1. static/non-static overloads. Support for this was dropped in PHP 8, but had to be retained internally just for that one usage in FII, so getting rid of that seems quite high value. 2. type/meaning overloads, where certain parameters change meaning entirely across overloads. These are incompatible with named parameters and result in very unclear function signatures. They only become intelligible once split into separate signatures, which is not something PHP supports. Removing these is also fairly high value. 3. arity overloads, where behavior depends on number of parameters, or certain parameter counts are forbidden, but the actual meaning of the parameters does not change. Equivalent to a func_num_args() check in userland code. I think these arity overloads are pretty harmless. The function signature is meaningful and compatible with named arguments. My overall inclination here is to vote No on all the deprecations that involve arity overloads and vote Yes on the remainder. Possibly I'm missing some kind of complication that the arity overloads are causing? Regards, Nikita
