@Composable
private fun ZoomControls(
    zoom: Float,
    onZoomChanged: (Float) -> Unit
) {
    Row(Modifier.fillMaxWidth(), horizontalArrangement = Arrangement.Center) {
        ZoomButton("-", onClick = { onZoomChanged(zoom * 0.8f) })
        ZoomButton("+", onClick = { onZoomChanged(zoom * 1.2f) })
    }
}

ZoomControls(zoom) {
        zoom = it.coerceIn(MinZoom, MaxZoom)
    }

This is a bit confusing since being a Composable, I expect the lambda to be a

content: @Composable () -> Unit

instead of a callback.

Lots of composables take callback functions that aren't composables.

remember

,

Button

,

TextField

, etc. It doesn't make sense for callbacks to be composable, since they represent events, not descriptions of UI.

in the case of remember it´s fine, because I don´t expect it to return a representation in the ui. when I see an Composable in Uppercase, I expect that if the last param is a trailing lambda is for taking other Composables

Not sure what’s confusing about this – the parameter is named following the “on*” pattern, implying that it’s a callback, and it’s not marked

@Composable

, so it’s clear it’s not a composable. If it’s seeing code using the trailing lambda syntax, like

ZoomControls(zoom) { … }

, that’s confusing, there I’d agree and would probably rather write the lambda inside the parenthesis with an explicit parameter name (I’d do this for all callbacks). It would be nice to have a lint check warning against using trailing lambda syntax for callbacks.

Fwiw you're in good company in thinking about this, we've had a decent amount of internal debate on whether the API guidelines should take a strong opinion here or not