Has anyone ever talked about omitting braces for s...

# language-evolution

[Sam]

Has anyone ever talked about omitting braces for single-expression trailing lambdas? e.g. with(foo) bar() instead of with(foo) { bar() }. I'm sure there are any number of reasons why the grammar wouldn't work, but I still think it'd be cool 😄

[CLOVIS]

Yeah, I think about it all the time 😅

I'm sure that would make everything ambiguous though 😕

[Sam]

Infix functions probably screw it up. You wouldn't be able to distinguish between foo.bar(baz()) and foo { bar { baz() } }.

[CLOVIS]

it's even easier to break;

with(foo)
    bar()

is already ambiguous

[Sam]

I guess, since with(foo) could just be a single-arg function call

[Sam]

Oh well, it was a cool idea, briefly

[CLOVIS]

Maybe with another marker?

with(foo) <- bar()

[Sam]

Yeah, at that point you might as well just stick to the braces

[ephemient]

just be python ;)

with(foo): bar()

[Youssef Shoaib [MOD]]

Maybe with the previously explored of decorators?

@with(foo) bar()

Or maybe we could only do it with other decorators but we still need a lambda for the expression?

@with(foo) @with(baz) bar()

[CLOVIS]

I much prefer the proposed

context val foo
context val baz
bar()

from the context receiver proposal—though it doesn't seem to have made it to the new one

[Youssef Shoaib [MOD]]

I completely agree! For a general dsl-like function though, we'd like a way to avoid nesting when the lambda is a single expression that (possibly) is another dsl function with a lambda. Decorators solve that, but I wonder what they'd actually look like in Kotlin. IIRC they were presented briefly and only on named functions, not on lambdas