[jira] [Comment Edited] (GROOVY-9612) Should parse parenthesis and bracket after newline correctly

["Paul King (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149158#comment-17149158 ] 

Paul King edited comment on GROOVY-9612 at 7/1/20, 6:36 AM:
------------------------------------------------------------

I would phrase things differently to what Daniel said. Groovy has never (at least not since 1.0) supported the syntax:
{code:java}
println
(
  100
)
{code}
as a single statement. This ties back to semicolon being a statement separator in Groovy (not statement terminator like in Java).
 The general rule of parsing is that end of line terminates the statement except when it wouldn't validly end a statement.
 So, this is fine:
{code:java}
println (
  100
)
{code}
But {{println}} on its own could be a property. You can work around this limitation in various ways, e.g. using a trailing backslash:
{code:java}
println \
(
  100
)
{code}
We do make exceptions to the general rule, e.g. we do lookahead in various situations including closures, e.g. the above limitations don't exist and workarounds not needed for:
{code:java}
def println(Closure c) { println c.call() }

println
{
  100
}
{code}
When designing Groovy 3, we looked at whether we could also do lookahead for brackets. Adding such support would be a breaking change. This is different to the closure case since lookahead for closures has been around for a long time. As an example, this code:
{code:java}
binding.variables.println = 42

println
(
  100
)
{code}
prints nothing and returns 100 in all previous Groovy versions. If we supported the lookahead for brackets, it would print 100 and return null. We haven't been convinced that such a breaking change and added complexity to the parser would be justified for marginal extra Java compatibility. It isn't a goal of Groovy to be 100% Java compatible for all styles, we just try to be very close whenever we can.


was (Author: paulk):
I would phrase things differently to what Daniel said. Groovy has never (at least not since 1.0) supported the syntax:
{code}
println
(
  100
)
{code}
This ties back to semicolon being a statement separator in Groovy (not statement terminator like in Java).
The general rule of parsing is that end of line terminates the statement except when it wouldn't validly end a statement.
So, this is fine:
{code}
println (
  100
)
{code}
But {{println}} on its own could be a property. You can work around this limitation in various ways, e.g. using a trailing backslash:
{code}
println \
(
  100
)
{code}
We do make exceptions to the general rule, e.g. we do lookahead in various situations including closures, e.g. the above limitations don't exist and workarounds not needed for:
{code}
def println(Closure c) { println c.call() }

println
{
  100
}
{code}
When designing Groovy 3, we looked at whether we could also do lookahead for brackets. Adding such support would be a breaking change. This is different to the closure case since lookahead for closures has been around for a long time. As an example, this code:
{code}
binding.variables.println = 42

println
(
  100
)
{code}
prints nothing and returns 100 in all previous Groovy versions. If we supported the lookahead for brackets, it would print 100 and return null. We haven't been convinced that such a breaking change and added complexity to the parser would be justified for marginal extra Java compatibility. It isn't a goal of Groovy to be 100% Java compatible for all styles, we just try to be very close whenever we can.



> Should parse parenthesis and bracket after newline correctly
> ------------------------------------------------------------
>
>                 Key: GROOVY-9612
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9612
>             Project: Groovy
>          Issue Type: Wish
>          Components: parser
>    Affects Versions: 3.0.4
>            Reporter: Laurent RICHARD de LAPRADE
>            Priority: Major
>
> For example, this should compile correctly. Current groovy parser forces coding style format which is not the one we choose when we code Java. 
> {code:java}
> import java.io.*;
> import groovy.io.*;
> def dir = new File("C:\\");
> dir.eachFileRecurse
> (    
>     f
>     ->
>     println(f.name)
> );
> {code}
> groovy.lang.MissingPropertyException: No such property: eachFileRecurse for class: java.io.File
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)