Re: Revisiting the "Named Arguments" RFC

On 12/01/2014 19:35, Andrea Faulds wrote:

This is why I proposed earlier that we should make => in function calls work identically to array syntax, such that { const bar = "foobar"; foo(bar => 3); } would be the same as foo("bar" => 3); However, strings are quite inconvenient. So I suggest a new, bareword-only syntax, namely the colon. foo(bar: 3); would never mean the constant, and only mean the parameter named bar. We could then add this syntax to array declarations: [bar: 3, "foo" => 7] It would allow a shorter form while avoiding inconsistency with array syntax.

The question, is, is the parser robust enough to guarantee that the following will all be parsed correctly: do_soap_call(namespace: 'foo'); check(if: $arriving === true, true: 'Hello', false: 'Goodbye'); $callback = array( function: function() { }, array: array( ) ); I can't think of a case off the top of my head where it would be *theoretically* impossible, but that doesn't mean it would be trivial to implement, and if there were any cases where it couldn't be used, I'd personally much rather it didn't exist at all. (And what about secondary parsers, e.g. syntax highlighters?) I'm also not convinced that it's something worth having more than one way to write, as it just makes code harder to read for new coders: will it be obvious that [bar: 3] is the same as ['bar' => 3], but not the same as [bar => 3], except when it is, because of "undefined constant, assumed string" fallbacks...? I think I'd personally lean towards using a $ to mark named parameters, and simply not allow dynamically choosing which parameter gets passed (that strays close to "variable variable" territory anyway, of which I'm not a fan). If I think of the function signature "function foo($bar) { ... }", I would tend to think of the argument as "$foo" not "foo" anyway, so it doesn't seem a stretch that "foo($bar => 3);" would mean "call function foo(), with argument $bar set to 3". Regards, -- Rowan Collins [IMSoP]