Hmm... in the other end, we can find ourselves choosing between:

Column {
    TopAppBar(
        title = { Text(text = "JetNews") },
        navigationIcon = {
            VectorImageButton(id = R.drawable.ic_jetnews_logo) {
                openDrawer()
            }
        }
    )
}

or

Column {
    TopAppBar(
        title = { Text(text = "JetNews") },
        navigationIcon = {
            VectorImageButton(
                id = R.drawable.ic_jetnews_logo, 
                onClick = {
                    openDrawer()
                }
            )
        }
    )
}

I must say the latter one is to prefer, because you understand what the actually action does (is it

onClick

,

onLongClick

or something else...?). But not using the lambda method, will we miss some functionality, or are all the options/benefits there ?

Found another example of "ambiguity" when working with this problem, the definition of a TabRow is like this:

@Composable
public fun <T> TabRow(
    items: List<T>,
    selectedIndex: Int,
    scrollable: Boolean,
    indicatorContainer: @Composable()
(List<TabRow.TabPosition>) → Unit,
    tab: @Composable()
(Int, T) → Unit
): Unit

At the definition now (as I understand), the lambda points to the latest added parameter,

tab: @Composable() (Int, T)->Unit,

but it could in theory be the

indicatorContainer: @Composable() (List<TabRow.TabPosition>) -> Unit

. So to make that happen, we need to override and switch theese two parameters ? I rather stick to using parameter reference here... BTW: If there was this

@Lambda

annotation defining which one was the defined lambda, when an ambiguity existed, it would be clear for everybody, and you could define it anywhere in the sequence of lambda likes, but only one (at this time, maybe named ones later

@Lambda(MyLambdaName)

. How those should be referenced in the code structure, I'm not sure... )

with named parameters it’s clear

but if named parameters are ommitted, it’s odd

because

Button { println("Hello world") }

and

Button("Click me") { println("hello world") }

(the former is an error in this particular case, to be fair)

but the problem is that the semantic of the lambda is different in the overloads of the same function, which i think we should probably try and never do

so you could say that for button, handler is most important

and then the correct form of the former is

Button({ Text("Click me") }) { println("hello world") }

we decided the opposite… that it was more important to have the consistency of a trailing lambda on the composable implying hierarchy

but i can see the argument for either

😃😃

On the other hand, I rather don't like that the order of something (here parameters) should define what that something (parameter) should do. It fights against kotlins flexibility or conciseness. Instead of an annotation (@Lambda) there should rather be a "lambda" prefix for that perticular lambda-possible parameter, which you could define when you called that function... (I'll explain later).

and fwiw i don’t think API design should ignore parameter order anyway.

Here's my suggestion for lambda definition (and I know, it isn't good)...:

...
MaterialTheme {
   ModalDrawerLayout(
       drawerState = drawerState,
       onStateChange = onDrawerStateChange,
       gesturesEnabled = drawerState == Opened, 
       lambda drawerContent,  //<-- lambda prefix
       bodyContent = {
           AppContent(
                   openDrawer = {
                       onDrawerStateChanged(Opened)
                   }
           )
       } 
   ){       //lambda is drawerContent
      AppDrawer(
              closeDrawer = {
                  onDrawerStateChange(Closed)
              }
      )
   }
}

(for you who reads this, it will not work in kotlin (at the moment 😁) ) RG

In the API definitions it cold also be used:

@Composable
fun ModalDrawerLayout(
    drawerState: DrawerState,
    onStateChange: (DrawerState) -> Unit,
    gesturesEnabled: Boolean = true,
    drawerContent: @Composable() () -> Unit,
    lambda bodyContent: @Composable() () -> Unit ) //<- it clearly shows which parameter is the defined lambda (and it is simply overridable if it should be used otherwise), as shown in previous example.

(for you who reads this, it will not work in kotlin (at the moment 😁) ) RG

...or maybe better postfix... ("java_me" struck through)

@Composable
fun ModalDrawerLayout(
    drawerState: DrawerState,
    onStateChange: (DrawerState) -> Unit,
    gesturesEnabled: Boolean = true,
    drawerContent: @Composable() () -> Unit,
    bodyContent: @Composable() () -> lambda Unit ) //<- it clearly shows which parameter is the defined lambda (and it is simply overridable if it should be used otherwise), as shown in previous example.

(for you who reads this, it will not work in kotlin (at the moment 😁) ) RG

... or even more postfix ...

@Composable
fun ModalDrawerLayout(
    drawerState: DrawerState,
    onStateChange: (DrawerState) -> Unit,
    gesturesEnabled: Boolean = true,
    drawerContent: @Composable() () -> Unit,
    bodyContent: @Composable() () -> Unit lambda ) //<- it clearly shows which parameter is the defined lambda (and it is simply overridable if it should be used otherwise), as shown in previous example.

(for you who reads this, it will not work in kotlin (at the moment 😁) ) RG

And it could be "grayed" when it was written last, since this is the default behavior. Otherwise the keyword, overrides the last one as this:

@Composable
fun ModalDrawerLayout(
    drawerState: DrawerState,
    onStateChange: (DrawerState) -> Unit,
    gesturesEnabled: Boolean = true,
    drawerContent: @Composable() () -> Unit lambda, //<-
    bodyContent: @Composable() () -> Unit)
// Here drawerContent is lambda.

(for you who reads this, it will not work in kotlin (at the moment 😁) ) RG