Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127432
Message-ID: <ea5fc915-2dd4-4f5b-a858-d80a7293c273@sandfox.me>
Date: Fri, 23 May 2025 04:24:55 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Forced named parameters
To: Yogarine <alwin@garsi.de>
Cc: internals PHP <internals@lists.php.net>
References: <E70F7EA1-0513-4B1D-894F-85D773451587@garsi.de>
Content-Language: en-US
In-Reply-To: <E70F7EA1-0513-4B1D-894F-85D773451587@garsi.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: sandfox@sandfox.me (Anton Smirnov)

Hi Alwin

On 19/05/2025 19:37, Yogarine wrote:
> Moreover, what if I don't need a variadic parameter, but would like to declare that the function's interface requires named arguments (because I don't want to be tied to locking parameters to specific positions).

If you don't need a variadic, you write an ellipsis without a variable 
name, like in my example:

 >> function f(Type $pos1, Type $pos2, ..., Type $named1, Type $named2)

> So instead I'd propose to implement this using an attribute (e.g. `#[RequireNamedArgs]`) instead. That way, you could even make it so that only specific arguments are required to be named. It's also syntactically backwards compatible, so this feature wouldn't make your code break compatibility with older versions of PHP, and could be made available in older PHP versions using static analysis.

Please explain the syntax you propose about this part:

 > That way, you could even make it so that only specific arguments are 
required to be named

because I see only 2 ways to call it:

   #[AllArgsAreNamed] function f (/* ... */)

and

   function f($arg1, #[AllArgsAfterThisOneAreNamed] $arg2, $arg3)

because

   function f($arg1, #[NamedArg] $arg2, /* positional again */ $arg3)

doesn't make sense, you cannot specify a positional argument after a 
forced-named because it would be impossible to fill position 2 on the 
function call.

Both cases are better covered by my syntax.

 > It's also syntactically backwards compatible

Making it syntactically incompatible is what avoids the BC break and 
relying on userland static analysis seems to be discouraged in this 
community.

Consider this scenario:

let's say version x is the first one with the feature

   #[RequireNamedArgs]
   function f($a, $b, $c) { /* ... */ }

   f(1, 2, 3); // works in x-1, broken in x

so this feature should at least go through the deprecation-like phase, 
and be fully accepted only in a major version, which just means that it 
cannot be fully used until the next major version. That defeats the 
purpose for me.

Anyway, the biggest problem for me, why I'm not considering writing an 
RFC for now, is that I don't know what to do with func_get_args() and 
reflection.