We ve decided against typealiases for this sort of thing in

Question

We ve decided against typealiases for this sort of thing in the compose API An aliased type name can tell you a bit about what the intended usage is but then you still have to hold in your head look up what the type actually is in order to provide one In contrast the function type clearly describes the type and the parameter name describes its purpose you have everything you need to know at a glance even if it s an API you don t use often enough to commit to memory

Big Chungus · Answer

Would be good to have typealias provided regardless even if not used internally for convenience when declaring your own composables

olonho · Answer

Nobody prevent you to create such typealiases and use them as needed

Big Chungus · Answer

I know it s just standartisation issue Instead of having users declare their own and then confuse others when sharing code I think it d be beneficial to have some official typealiases provided so we re all on the same page

Big Chungus · Answer

Again it s a mater of convenience so not having them is definitely not the end of the world smile

Adam Powell · Answer

Agreed about it being good to have standards the full function type is the standard slightly smiling face

Adam Powell · Answer

In the presence of typealiases users need to know both expressions of a concept to be productive in a codebase

Timo Drick · Answer

Maybe the only problem is that IntelliJ IDE do not show the Composable annotation in the preview So maybe in the future it could also display the annotation than it is clear that this parameter expects a composable

Timo Drick · Answer

Or maybe like in other cases the IDE could just show composable instead of the type

Martin Nowosad · Answer

```function type clearly describes the type and the parameter name describes its purpose``` I beg to differ `title` definitely doesn t feel like you have to pass in a function and seeing ` gt Unit` as parameter doesn t express anything neither

Martin Nowosad · Answer

a `Composable` as type would be easier to understand and more readable

Martin Nowosad · Answer

I agree with Timo if IntelliJ could show the annotation then this would also help

Martin Nowosad · Answer

but maybe I m also not just used to it Personally I find code that is built around lambdas builder methods difficult to read

Timo Drick · Answer

Yes but for me the felxibility worth it Because in the legacy material design views it is very hard to modify it to your needs And at the end you have to build everything from scratch I like the courrect trend in compose to make the things much more adaptable Still many things i would like to adapt are internal but much better than in the old view system

Adam Powell · Answer

Agreed that not showing the annotation here hurts legibility That s only part of it though the formatting of this pop up in general should also evolve Adding the annotation without allowing the pop up to format into additional lines will exacerbate the existing noisy hint popup problem that already appears with other kotlin APIs that include more than a few parameters and heavy use of default values

gildor · Answer

I think showing annotation for lambdas in such popups is very noisy something like an icon would be nice similar how suspend functions are marked