Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120688
To: Nikita Popov <nikita.ppv@gmail.com>, Ben Ramsey <ben@benramsey.com>,
	=?Windows-1252?Q?M=E1t=E9_Kocsis?= <kocsismate90@gmail.com>
CC: Levi Morrison <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded
 signatures
Thread-Index: AQHZqDNOzscc7EYmMEqrpB8lsTz/k6+dZgkAgAAWZYCAAFdR/w==
Date: Tue, 27 Jun 2023 01:25:59 +0000
Message-ID:
 <BN7PR05MB403329C9AB32DEC445864B54DE27A@BN7PR05MB4033.namprd05.prod.outlook.com>
References:
 <CAH5C8xV2ph8GOTDVZjK968+_AKLrrgkoTNDZpK6oE71PXhrOPQ@mail.gmail.com>
 <6B872612-2F31-49E0-949C-CDF6FB2B9BE4@benramsey.com>
 <b19e3af5-6505-40be-b84b-49ba432c46d0@app.fastmail.com>
In-Reply-To: <b19e3af5-6505-40be-b84b-49ba432c46d0@app.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels:
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [2yWO3uplFvLei2RkJA2zgRHGxstVdv9m]
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN7PR05MB4033:EE_|PH0PR05MB7914:EE_
x-ms-office365-filtering-correlation-id: 5af37361-9a4b-4ac3-0d81-08db76ad7666
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 DyiPgFNTNx+8K+pwbZ029clccelrhHgdf/0Y5eemb5/YgtdOG02cbRTlDSV1k/w+8rkcInMrfQ+/IIgJz+2VGfv2fFupjbXJR0iMMcyVLcSAVFU8FhmSqG+7K8gctkYpsffl2hhQhMk9x6fXFBuPY6Mo6q/jWVu5m1v2OnWs5o3gbbcTFKgkFPLvGxkYv3NLTrzw52ScuOh4DklHkfxAjWj3KZDnnnKm3J5UXr17AX4hLtEXi3/7Cva+UtJOelqvwGdQ/YCFqyHmzynwccYGm+D69ygEzJ4+SHBEudrtMXBPIktAXogeliitQEhZje5qeS9nGto1pJikiv+qR49CL0pzJRb9oQwRDF47rdP+OZgx7XKpzENkFfpmvWmUNvN5w3abWbReAErUhHp1T/Zo5oTZ30LzYJpnwSwllC9S+He9CnNxB7Mk/8HLjRLdaJtfGrq834+EchD38vyZSdVs/NnFqQOCAE/HvTUhZ2d703/qGtHEhoQ2jftuQbRf2VNqaKn8e8iax2HiJNjRy8D5XU72c2h1HNOKiIThFeS+x8o=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?Windows-1252?Q?+3huZd/fD1vJMIs+dm+fHX67F40VCDO6S7CzX8yC0zkmF+LeeC5LMdpx?=
 =?Windows-1252?Q?A8KZYDtQ18Yg4jV1364b1GghiY+FH1V9Bg0p828cyoUx3rouyLCGTDNV?=
 =?Windows-1252?Q?EsowAGS51dBMBR5NqWVig4huWLFDGNUWcjPeeavheDO3lkvdyxQWT5ne?=
 =?Windows-1252?Q?TNScEgOMlheY53QeKQCY8zNK1rkEsznMjo1p/D4fvcdV5eVn7XcgiVSv?=
 =?Windows-1252?Q?O2u5gIyxcMNIUMBcvHcJVesZfumAMDrx1CLKlrDbZoBy4H6yqQgDunHt?=
 =?Windows-1252?Q?AvA91ZHmgtbfKLRGh+3sL4ejHur3lMN9IG+HjO9olUWvh+KHFq2c8c5w?=
 =?Windows-1252?Q?lVONs9a5Xv18trP7DvGXOXB3QrDFnH5vZZGOq92Z4cZJZBgEt3AfJms4?=
 =?Windows-1252?Q?NtLZ6Yhh5AuJoYUR5KAaAzpPld6A+3Lny7OZ35ds8HJVu5Y/A0RVGK5O?=
 =?Windows-1252?Q?NHchLseFzagaT4fORf3ov5xxow7155HnHIO58iN4Ydg2MgYza+jl/EWH?=
 =?Windows-1252?Q?qBpQsGiVpZNI6V3amqciTidZe3PXU3s4OdcBBhxmvlU3BiVzNbNiiJiz?=
 =?Windows-1252?Q?pwsGp+M9tGYmGSNnWu64NAAtBG0lKmwpAO68E9pNPmg87+qf4KuEMusB?=
 =?Windows-1252?Q?xkDgcJpTmFavkXP8UHOmBQnrPbHHBnQetm7b8RjF7pDiB4dIE8oEp+dT?=
 =?Windows-1252?Q?CRh5TXmdO0BkNZMImiKJw8gOG5o6GoUvzLvr9QHO2kefFye7MauMKACt?=
 =?Windows-1252?Q?NXTeRv9KYbPTuOb0Qpo2v+Aa5P77Scad8MJ7HdvU0a505wqDjkhiZT1H?=
 =?Windows-1252?Q?ZnSyRH247zaRTRdfG7qxULX6hR8JgAQBq4vMBens11eyD1G59IyrDunC?=
 =?Windows-1252?Q?t9DjwA2+5McYzOt/nfzV8jdU+AYgbXCyHYbvDEcr4bilqxpZ0zf0qyJ5?=
 =?Windows-1252?Q?cQNsnpombrV/aRZMIOwGpqCQkDn5mxojFdDEpI2SNTdPjoDiSTtV2oCr?=
 =?Windows-1252?Q?1A6yViYm9apVOTSEvj0QnHTyOV7Vbq/1eaAzofmjPLdPZz+tnW9H7y4U?=
 =?Windows-1252?Q?m2rYAr9/1GHkCrHYQLSoqvD7kN7KPHB88C13yzDckWwJz0CUUtkMoj4K?=
 =?Windows-1252?Q?GT6TNXmFbDHr+djra3QYqHEpajVcvIOWGHrXKb4/1ExmJ/41A1evlQkd?=
 =?Windows-1252?Q?XVTPXGZErA489gxYF+A/l92SxXEwBS8/09JkLeeEGSu2U2tXXmNyxLUV?=
 =?Windows-1252?Q?kt1U26ODLt+WvUKM7zETNrzyzkQ9s47MW4bwK9PMKZLUX1LgRZVAecny?=
 =?Windows-1252?Q?LB5XZQ=3D=3D?=
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR05MB4033.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 5af37361-9a4b-4ac3-0d81-08db76ad7666
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2023 01:25:59.0414
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB7914
Subject: Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded
 signatures
From: theodorejb@outlook.com (Theodore Brown)

On Mon, June 26, 2023, at 14:43 Nikita Popov wrote:=0A=
> On Mon, Jun 26, 2023, at 20:22, Ben Ramsey wrote:=0A=
> >=0A=
> > I voted =93no=94 on `array_keys()` because I do not see these as two di=
fferent function signatures. To me, the single signature should look like t=
his:=0A=
> >=0A=
> >     function array_keys(array $array, ?mixed $filter_value =3D null, bo=
ol $strict =3D false): array {}=0A=
> >=0A=
> > I voted =93no=94 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:=0A=
> >=0A=
> >     public function setDate(int $year, int $month, int $dayOfMonth, int=
 $hour =3D 0, int $minute =3D 0, int $second =3D 0): void {}=0A=
> >=0A=
> > In the same way, with `IntlGregorianCalendar::__construct()`, `createFr=
omDate()` and `createFromDateTime()` could be combined as:=0A=
> >=0A=
> >     public static function createFromDate(int $year, int $month, int $d=
ayOfMonth, int $hour =3D 0, int $minute =3D 0, int $second =3D 0): void {}=
=0A=
> =0A=
> So commonality here is that these are all arity overloads.=0A=
> =0A=
> I think there's three different kinds of overloads in involved in the RFC=
:=0A=
> =0A=
> 1. static/non-static overloads. Support for this was dropped in PHP 8, bu=
t had to be retained internally just for that one usage in FII, so getting =
rid of that seems quite high value.=0A=
> =0A=
> 2. type/meaning overloads, where certain parameters change meaning entire=
ly across overloads. These are incompatible with named parameters and resul=
t in very unclear function signatures. They only become intelligible once s=
plit into separate signatures, which is not something PHP supports. Removin=
g these is also fairly high value.=0A=
> =0A=
> 3. arity overloads, where behavior depends on number of parameters, or ce=
rtain parameter counts are forbidden, but the actual meaning of the paramet=
ers 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.=0A=
> =0A=
> My overall inclination here is to vote No on all the deprecations that in=
volve arity overloads and vote Yes on the remainder.=0A=
> =0A=
> Possibly I'm missing some kind of complication that the arity overloads a=
re causing?=0A=
=0A=
=0A=
Currently the following code returns only the array keys that loosely equal=
 null [1]:=0A=
=0A=
    array_keys($array, null)=0A=
=0A=
If the function is changed to a single signature with $filter_value default=
ing to null (with an argument count check to preserve the above functionali=
ty), 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.=0A=
=0A=
To prevent confusion, the function would at least still need to be document=
ed with two separate signatures in the PHP manual, which goes against one o=
f the RFC goals of automatically updating signatures based on stubs.=0A=
=0A=
So from my perspective there is value in deprecating arity overloads: it av=
oids confusing behavior changes and the need to manually keep the overloade=
d signatures documented and in sync in the manual.=0A=
=0A=
Regards,=0A=
Theodore=0A=
=0A=
[1]: https://3v4l.org/Sld4S=