Make parentheses around function calls optional


Groovy has a neat feature where you can drop the parentheses around function calls, making the code appear much more DSLey, so, instead of


You would have

add SomeObject()

I for one would welcome the addition of this feature to the already wonderful tooling for creating internal DSLs.




I’m aware, but what I’m proposing is more general (infix function require an explicit right hand argument, my proposal does not, and my proposal could be generalised to omit any function call parentheses except for argumentless calls, so f(a, b, c) could become f a, b, c.


That would be very interesting in my opinion. Another option would be adding a function modifier like infix (prefix would be a good name) that would allow us to use the function without the parentheses.


I ran into this kind discussion somewhere already.

Basically the problem in complexity of parsing function call without parentheses.

Also in Groovy it doesn’t work well and causes many problems when compiler “misunderstands” the code.

Finally the function call without parentheses still requires commas to separate parameters, which still doesn’t look DSLish.


Yeah, certainly the single parameter is the cleaner usage, but still “setOf 1, 2, 3” looks pretty clesn and DSLish to me.

Sad to hear that Groovy has problems with it (but the groovy feature is even more complex since it allows removing dot access, which I’m not proposing here). Besides that, I naively don’t see the problem with parsing: whenever you wncounter a function identifier followed by an expression, instert an open paren in the parse tree and set a boolean flag to true. Whenever the next token is an end of statement, insert a close paren. This disallow nested parenless functions, but that’s sensible in my view.


Here is a simple but confusing example:

fun func1(i: Int): Int { return i * 2 }

func1 10 + 15

How do you want this to be interpreted func1(10) + 15 or func1(10+15)?

What if instead of 15 we have conditional expression? How far ahead compiler should look to figure out if function call is over or not?

Other examples:

val list1 = listOf<Int>(1, 2, 3)

listOf<List<out Any?>> emptyList(), list1[1]
listOf<List<out Any?>> emptyList(), list1.get(1)

These 2 line are equivalent, but second one can use any method applicable to both last parameter and return type of the method.

Of cause the priority of operations can help, but it is complex and confusing as is without adding the function call into them. It also makes code less readable.


I’m also not a fan of this idea. The problem as @cabman pointed out is that this will make anything but the most basic calls a nightmare to read and understand.
We already have a similar problem with infix functions, because there is no way of specifying precedence for them.
I see why this would be great for DSL like constructs but I don’t think it’s worth adding this just for that alone especially as it degrades the language if used for anything else.


Sometimes I also wish omitting the parens in function calls were possible. But it should not be added as long as it causes ambiguous syntax.


In lights of your comments, I’ve become inclined to enable this behaviour with a keyword/modifier akin to the infix modifier. That way, msking this behaviour available would be responsability of whoever creates the function, not whoever uses it.
As for precedence, please excuse me if I’m being naive, but I see it this way: if the parser sees a token that is a function identifier, and the next relevant token is not an open paren, then all the text until the next coma or statement terminator should be understood as a single expression. Thus
fun 1 + 2 is unambiguously interpreted as fun(1 + 2) and if you wanted other interpretation you would have to use parens.
I fear I don’t understand what’s the problem with the list examples.


Examples with List can be interpreted as

listOf<List<out Any?>>(emptyList(), list1[1])
listOf<List<out Any?>>(emptyList(), list1.get(1))


listOf<List<out Any?>>(emptyList(), list1)[1]
listOf<List<out Any?>>(emptyList(), list1).get(1)

What do yo mean by “statement terminator”? Of cause other than ; which everybody hate.

Yet another example:

func1(3 + 5)
    , 2.0

Compiler cannot figure out the meaning of expression in parentheses without looking forward.


An statement terminator is either a semicolon or an endline in kotlin (setting aside comments) (not sure if ‘terminator’ is used in the kotlin spec but I see the term often in defining programming lsnguages).

As per one of my previoud comments, my idea is that the list examples would be understood as in your second translation.

Thanks for the second example, since it helps me flesh out my idea. As per my previoud reply, that snippet would be not only confusing, but illegal. However, func1 2.0, (3+5) would be legal.


The EOL is not terminates anything. For example:

fun func1(i: Int = 0, r: Double = 0.0) {
        i *

is very legal 2line expression.

The example you mentioned in last paragraph is legal inside function’s parentheses. Also as I said code func1 (3+5), 2.0 should also be valid, but compiler should look forward for comma to understand how to interpret expression in parentheses.


I think one way to resolve the ambiguity is to let the user explicitly opt-in for this feature.
For example, we can make it only doable in a closure since it’s basically a feature for DSL.
The user has to do something like

fun closureExample(@AllowPrefix c: Foo.() -> Unit) { ... }

Only in this way, the user can write:

closureExample { add “abc” }

given that the class Foo has method

prefix fun add(s: String) {}


In @sam.zhou case there is not much ambiguity in the first place. However one of the problem is if the actual parameter provided as complex expression. This is the same problem as with infix function.

The more complex problem I don’t want to have is when function takes multiple parameters.

Also original request was to make parentheses optional. This is not a case with infix function and suggestion by @sam.zhou sounds like to follow the same pattern: if developer provided modifier prefix then no parentheses allowed, otherwise they are required.


Groovy can do this because end of line is much more of a statement Terminator unless the line is incomplete.

Some additional ambiguities. What if we are nesting calls:

fun1 fun2 a, b

Is that fun1(fun2(a,b)) or fun1(fun2(a),b) or fun1(fun2)(a,b)? All could be valid.

What if I need parentheses in my parameter expression?

function (a + b) * c

I could see this causing bugs


Kotlin developers decided against omitting braces based on Groovy experience. It produces a lot of problems and the only place it could be used is gradle-like dsl. For that one can always use groovy wrapper, especially because it much lighter than kotlin compiler. Using brace-less syntax in actual non-dsl code is a terrible mistake.


If Kotlin had builtins for arrayOf/listOf then I don’t think I’d see a big need for this feature. In general I find that infix functions can be used in DSL context to provide a marginally more verbose, but much more readable, DSL syntax:

collect { data from source into dest } <-- infix fns from, into defined in scope of collect DSL closure.