<@UJBD8E5TM> I saw your talk at KotlinConf on Compose, and specifically about the Single Child Compo...

# compose

[Andrew Kelly]

@Clara Bayarri I saw your talk at KotlinConf on Compose, and specifically about the Single Child Composable Problem you mentioned. Is it not possible for something like a Button to query the number of children in the lamba and throw a warning if its more than 1? That’d force me as a developer to then include a Row or Column to wrap multiple children, the Row/Column children lambdas would be unbounded in the number they could include.

[mzgreen]

I wouldn’t be surprised if those multiple views are drawn on top of each other if no row/column is explicitly added (just like framelayout does it). But maybe I’m thinking too much in terms of current UI framework.

[Andrew Kelly]

In the talk they mentioned possibly having a sensible default, like wrapping them in a Row automatically.

[Louis Pullen-Freilich [G]]

There's no way to query the number of children in the lambda (currently, anyway) - it's just some arbitrary code that will be executed during composition - it may result in 0, 1, or many children. It's theoretically possible to do static analysis at compile time and throw a compilation error, but that's very tricky to do and would require a lot of work in the compiler layer

[Adam Powell]

More than that though, it complicates the type system in ways that can't be hidden from developers who haven't reached a certain level of sophistication yet. It implies a form of inferencing that would make implementation detail changes deep in other composable functions binary incompatible, and/or the need to forward-declare child count everywhere using something akin to contracts.

[Andrew Kelly]

Then perhaps as @mzgreen suggests the Composables should just stack like a FrameLayout if we declare more than 1 for something like a Button. Then as a developer when I Preview the composable it’d render all strange and I’d be like “oh yeah, I need to define a Row/Column/ConstraintLayout to have them laid out properly”. Sensible defaults are fun until they’re different, e.g. if the sensible default for Button is to wrap the children in a Row, but the sensible default for Card is to wrap the children in a Column, then things might get confusing to the uninitiated as to why things magically work, but in different ways.

[mzgreen]

Yes that's exactly what I was trying to say, thanks :)

[Adam Powell]

Yeah, that's where we were at for a while too. 🙂 It started getting less and less defensible in practice, especially with some composables that really blur the line between being this kind of slot content or a layout itself. The fuzzier the line got, the less sensible that became as a default

[Adam Powell]

At some point it becomes a judgment call