Jira (PUP-4398) Splat unfolding not supported in method call syntax

[Henrik Lindberg (JIRA)]

Title: Message Title

Henrik Lindberg commented on PUP-4398   Re: Splat unfolding not supported in method call syntax The surprising effect observed is because if there are parentheses there, they are assumed to defined additional arguments - the example results in an _expression_ equal to that below (where explicit parens have been inserted to show what the parser thinks this means): (((*[1, 2, 3]).notice(*[4, 5, 6])).notice(*[4, 5, 6])).notice {code:puppet}   That effect has nothing to do with splatting, nor "eating the return value", nor "first chain call uses parentheses". This has the same "problem": {code:puppet} 1.notice (2).notice (3).notice Rewriting the first example makes it work: (*[1, 2, 3]).notice() (*[4, 5, 6]).notice() (*[4, 5, 6]).notice() From a documentation standpoint, it is worth pointing out the difference between: 1.notice() (2).notice 1.notice (2).notice i.e. "if you have no additional arguments, you must use () to indicate that there are no additional arguments if your next _expression_ is a parenthesized _expression_. Alternatively you can separate the expressions using a semicolon". 1.notice; (2).notice As a human it is easy to assign meaning to whitespace - the parser is seeing something like this: 1 . notice ( 2 ) . notice It is now easier to spot the ambiguity that the parser resolves by giving "arguments in parentheses" higher precedence. Add Comment   This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.