On Fri, Jun 5, 2020 at 12:45 PM Christian Schneider <cschn...@cschneid.com> wrote:
> Am 05.05.2020 um 15:51 schrieb Nikita Popov <nikita....@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. > Right. It should be possible to use keywords. It's a bit harder than just replacing T_STRING with identifier, but I don't see any fundamental reason why it shouldn't work. > 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. > If we ignore the philosophical question of whether having positional parameters after named is a good idea, this mostly comes down to technical complexity. Enforcing the "named after positional" restriction is a simple compile-time check. Without it, we would have to duplicate a large number of argument sending instructions just for this special case. This is basically the same reason why we don't support "foo(...$args, 1)". That's perfectly legitimate code, but supporting it seems like more technical complexity than it's worth. > 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). > Separating positional & named variadics / unpacks in that way is certainly a possibility, but I don't think it's the best choice for PHP. In Python this is pretty much required, because Python has distinct list and dictionary types. In PHP these are combined in one data structure, which also allows us to combine them for the purpose of variadics. Combining them makes sure that existing code using variadic forwarding will "just work" with named parameters -- but of course, it also means that some code will accept named parameters even though it was not explicitly designed with that in mind. There's a trade-off there. Regards, Nikita
