Re: [RFC] Named arguments

Am 05.05.2020 um 15:51 schrieb Nikita Popov <nikita.ppv@gmail.com>: > \I've now updated the old proposal on this topic, and moved it back under > discussion: https://wiki.php.net/rfc/named_params First of all I really like this approach to Named Parameters: It seems to fit well with the rest of PHP. Note: I'm using the key: 'value' syntax instead of key => 'value' here but that's just because I prefer that syntax and think it more naturally extends to stuff like the shorthand syntax under "Future Scope" but that's not a prerequisite. I have two questions regarding to the Named Parameters which are not related to the LSP discussion. They might be restrictions of the current implementation mentioned in the RFC as opposed to design restrictions: 1) Could keywords be allowed as parameter names? Currently using class: 'foo' throws a syntax error. 2) Could positional parameters be allowed after named parameters for variadic functions? These two restrictions can be looked at separately and the only reason I'm bringing them up together is because the use case I'm looking at is HTML generation with something like a function div() being used as follows. Please don't discard the two questions just because you don't like this particular use-case, thank you ;-) div(class: 'error', div(class: 'title', "Error Title"), "Detailed error description...", ) The first issue is probably mainly a parsing issue and changing T_STRING to identifier seems to fix it though I'm not 100% sure if there are any drawbacks to this. What is the main argument for not allowing positional arguments after named parameters for variadic functions? Ambiguities could still be reported if I am not mistaken. A work-around for the second issue would be to require an artificial parameter name like content taking a string or array and then do div( class: 'error', content: [ div(class: 'title', content: "Error Title"), "Detailed error description...", ], ) but that's somewhat more verbose without any real benefit I can see. PS: Concerning "Future Scope: Shorthand syntax for matching parameter and variable name" I think allowing :$name is reasonable and thinking further along that line maybe variadic functions separating named from positional arguments could be done using func(...$positional, ....:$named) similar to Python's *args, **kwargs). - Chris