Forced named parameters

Hi Alwin

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.

Just chiming in, but I interpreted it as suggesting something like

 #[RequireNamedArgs('arg2', 'arg3')]
 function f($arg1, $arg2, $arg3)

Hi Anton,

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)

Ah, that hadn't really registered in my brain. So, if I want all parameters to be named, it'd be:

function f(..., Type $named1, Typ $named2) { /* ... */ }

I still don't think I like this syntax. I don't think one should taint the declaration of the parameters with how the arguments are expected to be provided. Forcing named parameters is a way of declaring additional requirements for the interface of your function, and attributes are the go-to approach for this – think #[\Override], #[\Deprecated], etc.

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.

In this case it would imply all params including and after the $arg2 have to be named as well. So in a way the attribute would replace your proposed ..., notation 1:1.

It's also syntactically backwards compatible

Making it syntactically incompatible is what avoids the BC break

I think I understand what you mean, but the way you write that phrase makes it read like an oxymoron.

What I'm trying to get at here is libraries could start using the new attribute to tighten their internal library code without requiring consumers to bump their required PHP version straight away.

relying on userland static analysis seems to be discouraged in this community.

I don't suggest we rely on static analysis. However, consumers of a library that starts declaring their params as explicitly named could start getting hints in their editor or static analysis tool before bumping their PHP version.

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.

The same applies to #[\Override] and any other attributes that change PHP behavior. If someone decides to use them in an older version of PHP (through a polyfill or what not) it's their responsibility to ensure that the restrictions that would otherwise be imposed natively by PHP are sufficiently replaced through static analysis.
It is true that this expects some discipline from library developers to properly apply semantic versioning to their pacakges, but I much prefer this over being forced to bump my PHP requirements, both in my libraries and in my applications, before I can start using a feature.

Besides, even with the ..., syntax, a certain amount of discipline is required from library developers at some point. Otherwise, even if I'm ont he most recent version of PHP, a package that starts enforcing named parameters without increasing their major version of their packages will just break my code once I update it.

In the end, the semantic versioning of PHP doesn't have to consider how a new PHP feature is emulated on older versions of PHP through polyfills / static analysis.

Again my main issue with the ..., syntax is that the goal of this feature is to hint that you intend to provide no guarantees about the positioning of the arguments. It shouldn't require backwards incompatible syntax, and there is precedent in how similar features have been implemented using attributes, namely: #[\AllowDynamicProperties], #[\Deprecated], #[\Override], #[\ReturnTypeWillChange] and #[\SensitiveParameter].

Additionally, I don't think a fatal Error should be thrown by this feature, at least not by default. An E_USER_NOTICE or E_USER_DEPRECATED would suffice to inform users that they have to take into account the guarantees around the signature of the function they're calling, but there is no reason to outright block otherwise perfectly fine function or method calls. I would like the ability to ease consumers of my library into using named arguments rather than forcing them to do so with a new major version release.
Having said that, using an attribute has the added advantage of being able to provide arguments to adjust its behavior. So for example, a throw argument could be provided to hint that PHP should throw an error, if you really feel so strongly about the proper usage of our functions:

#[\Named(throw: true)]
function f($a, $b, $c) { /* ... */ }

f(1, 2, 3); // Throws a `NamedArgumentException`.

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.

Well, that's another benefit of using attributes; since they define the usage of the function at a different scope, func_get_args() and reflection will just continue to work the same as they already do. One could consider adding a isNamed() method to the ReflectionParameter class, but that's about it, I think.
Of course, if you foresee other issues with func_get_args() or reflection, I'd love to hear them.

Anyway, I hope I don't come off as too harsh. Fact is I really like the idea. I just think it makes more sense, and will have a better chance of succeeding, as an attribute.

Oh, come to think of it, it might also make sense to offer the opposite: a way to force positional arguments. What if I don't want users of my function to rely on a parameter name, but I will guarantee the consistent positions of the parameters... Again, this would be much more straightforward to implement as an attribute (e.g. #[\Positional]) while I'm not sure how that could be implemented using traditional syntax.

Alwin