No, the syntax is that of function calls

# compose

[romainguy]

No, the syntax is that of function calls

[napperley]

Many function calls in Kotlin can have the parenthesis removed if only a lambda is being passed through, which reduces noise, makes APIs more declarative, and improves readability (promotes tall code).

[napperley]

Tall code is easier to read than wide code.

[Adam Powell]

The mental model isn't one of explicitly adding objects to a collection of children, the trailing lambda block is often itself the body content that will be emitted by the container at some point in its own composed hierarchy. That body content might be recomposed many times. Mixing content and configuration of the container can get confusing, plus there are many parameters to components that should not be provided/invoked more than once. A DSL-style receiver scope permits repeated operations where that may not be desirable from an API design perspective.

[Adam Powell]

We're also prioritizing making it easy to write components and use extract method refactorings to organize code/limit the width you're mentioning. Expecting developers to extract receiver scopes for configuration like this would mean putting a lot of burden on anyone trying to write library-grade components.

[bdawg.io]

if only a lambda is being passed through

This isn't the example you showed though. The example had more going on than just a scenario where parenthesis would normal be optional in common Kotlin code

[romainguy]

@napperley We are already using the trailing lambda syntax. But you are suggesting a new language feature (passing function parameters inside the trailing lambda)

[napperley]

Further more having the function parameters mapped to properties/functions in the object that is used as the context for the lambda.

[bdawg.io]

@napperley Do you have a sample of what such a feature might even look like?

[napperley]

Not sure what the feature would look like. Better understanding is needed of the problems mentioned by Romain Guy in relation to library authors/users. Would need to see if the idea (the feature) has merit. Could look at creating a feature proposal (aka a KEEP with some assistance from some people) if there is enough interest from the Kotlin community, and the Kotlin team.

[napperley]

Must admit it was a bit of a surprise that Romain Guy thought what I discussed previously sounded like a new language feature.

[romainguy]

That’s because the lambda is not a Widget itself

[romainguy]

It does not have properties to set like in your proposal

[romainguy]

So it sounded like wanted to set function parameter values from inside the lambda

[napperley]

Isn't Widget the context of the lambda, with the main problem being that function parameters cannot be mapped to the lambda context's properties (in a way that preserves immutability/performance)? This "language feature" might require persistent data structures ( https://github.com/Kotlin/kotlinx.collections.immutable/blob/master/proposal.md ) to be in place, and for Kotlin to have some proper immutability support (eg immutable data classes).

[bdawg.io]

The read-only collection implementations already honor that they should be read only. You have to explicitly try to cast them or bypass the type system through reflection before the stdlib collections would allow you to mutate the underlying data.