Note: Modifiers can play a similar role to XML attributes in the View system, but the type safety of scope-specific modifiers helps you to discover and understand what is available and applicable to a certain layout. Compare this with XML layouts where it was not always clear if a layout attribute was applicable to a given View.

This is copied from the Jetpack Compose Codelab "Layouts in Jetpack Compose". But it's not true as far as I know, because xml layouts does have the ability to tell if a layout attribute is applicable to a given View. Am I wrong or have I misunderstood what the doc says? Source: https://developer.android.com/codelabs/jetpack-compose-layouts?continue=https%3A%2F%2Fd[…]developer.android.com%2Fcodelabs%2Fjetpack-compose-layouts

凯歌好

There is nothing in the aapt resource compilation pipeline that checks that you've used a

LayoutParams

attribute like

android:layout_weight

in a place where the parent view will consume it. (e.g. in a child element of a

<LinearLayout>

tag.) What we have is a series of hardcoded android lint checks for a known set of attrs and parent views instead, which, while useful, is not as robust and requires running that separate tooling pipeline to verify.

Very clear. So the Compose way is more straightforward and safer (because the "check" side is automatic instead of requiring a couple of lint code), and fully covered.

Not quite fully, but much closer. 🙂 If someone writes a layout scope interface type for a composable container and does not annotate it with the

@LayoutScopeMarker

DSL marker annotation, it will leak available layout scope modifiers from the surrounding calling scope.

Just gone look into `@LayoutScopeMarker`'s code then

@DslMarker

(for the first time), and I think this kind of "Not quite fully" design is reasonable, at a relatively-perfect balance point. And, I have to say Kotlin is really cool.