My suggestion was not to consider allowing any whitespace to break
syntax ambiguity here, but only a newline after the opening square
bracket, i.e.:
// Still does not compile
final result = foo [ "some rather long literal string argument",
"another long literal string argument",
"and so on and so forth...",
]
// Parsed as foo([ ... ]) (not foo-index-access)
final result = foo [
"some rather long literal string argument",
"another long literal string argument",
"and so on and so forth...",
]
If the parser can do it, it would feel Groovy to me to allow it for this
use case (Of course it could still mean "index access", but how many
people would really write an index access on foo that way ?).
Groovy 3.0 is the place to ponder such questions, imho, because breaking
changes will come anyway afaiks (Java 9 modules), so you do it here, or
not for a long time...
Would be interested what others think, or if someone has a counter
example that makes it clear it is a bad idea to go down that route,
mg
On 06.04.2018 19:49, Daniel.Sun wrote:
Hi mg,
It's dangerous to let blank characters determine the grammar, which is
the lesson learned from Ruby ;-)
```ruby
def f(p)
return p * 2
end
f(3+2)+1 # 11
f (3+2)+1 # 12, have you seen the space between `f` and `(` ?
```
(you can try the above code at http://tryruby.org)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
