From the language perspective and idiomatic Kotlin, it would be nice to have a sketch on how could a generic system look like, even if still a plugin. By generic, I mean something that is not bound to this UI system, nor to Android or anything else. Like it was said on

suspend

function, let’s imagine for a moment we are doing an “incremental structure updates” plugin to the language, and let’s pretend we can have a (soft) keyword. In the true Kotlin spirit, we should be able to develop libraries and frameworks, and not just UIs. Like if we have

compose fun Data(name: String)

, then where the composition context comes from, how do you scope different DSLs belonging to different systems, etc. These are open questions, and they are probably out of scope of this very specific use case, but I find it interesting thinking about it and it would be nice to see what you folks think here.

Also the compose concept would need to retain most of the advantages of the receiver concept (explicit context, readable free form context initialisation in code block, function parameters optional etc).

Yes! There's no need for a keyword/annotation, you just take a receiver and patch its contents.

The topic on receiver was explained very well by @Leland Richardson [G]

Even so it would be a huge shame to not make feasible improvements to the Receiver concept, which is very relevant even though it has its downsides (as mentioned by @Leland Richardson [G]) like every other concept, and still has its place where it is a good fit for solving some problems.

agreed - would still love to see our proposal for receivers to get accepted (or something that solves the same problems)

Would be good to see the proposal taking the best bits from both approaches (Receiver and Function call) 😄.

the proposal i was referring to was just an addition to kotlin allowing for the specification of multiple/combined receiver scopes on a function, instead of limiting to one