According to the syntax the following is legal:
@{test}: println
However, because of a quick hack with annotations, the method call needs to be enclosed in braces, FTTB:
@{test}: {println}
The reason is that during the parser phase, for the annotation some code is generated of the form
DSL._at(_here: N_annotation[N_call[Any], T_call[Any]])
whereas it can only become known at compile time whether the RHS operand of @: is a script call or a method call; in the latter case the parser should have had generated ...N_code_normal[Any]..., but it could not know that then.
This bug may be repaired using a major design in the compiler: the parser should not do transformations; there should be proper ASTs for all subscript constructs, and only in the typer phase these should be transformed to regular Scala code.
According to the syntax the following is legal:
@{test}: printlnHowever, because of a quick hack with annotations, the method call needs to be enclosed in braces, FTTB:@{test}: {println}The reason is that during the parser phase, for the annotation some code is generated of the formDSL._at(_here: N_annotation[N_call[Any], T_call[Any]])whereas it can only become known at compile time whether the RHS operand of@:is a script call or a method call; in the latter case the parser should have had generated...N_code_normal[Any]..., but it could not know that then.This bug may be repaired using a major design in the compiler: the parser should not do transformations; there should be proper ASTs for all subscript constructs, and only in the typer phase these should be transformed to regular Scala code.