Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114476 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 29050 invoked from network); 14 May 2021 22:37:13 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 14 May 2021 22:37:13 -0000 To: internals@lists.php.net References: <1565EB81-57B7-49B0-A47C-342E0088A432@trowski.com> Date: Fri, 14 May 2021 23:45:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <1565EB81-57B7-49B0-A47C-342E0088A432@trowski.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Posted-By: 87.81.129.66 Subject: Re: [PHP-DEV] [RFC] Partial function application From: marandall@php.net (Mark Randall) Message-ID: On 14/05/2021 22:48, Aaron Piotrowski wrote: > I think it’s reasonable to allow passing more arguments to a partial since user-defined functions and closures allow this without error. But only userland functions, a relic from when func_get_args was the only way to handle varaible numbers of arguments. The documentation officially discourages func_get_args in favour of ...$ so I can definitely forsee the option of us deprecating that mechanism sometime in 8.x and and removing it in 9.0. I don't think it likely that it would go the other way of allowing unlimited arguments to internal functions. That being the case, IMO it makes more sense to introduce partials with the same behaviour as internal functions, passing more functions than specified (including partial arguments) should error.