A modern programming language that makes developers happier.

kotlinlang

&gt; 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%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fcompose%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fjetpack-compose-layouts#2|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 `&lt;LinearLayout&gt;` 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.

By contrast, the compose modifiers described in the codelab use kotlin's standard extension function mechanisms to implement the restriction at the API level.

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. :slightly_smiling_face: 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.

So if you're writing your own container receiver scope types, be aware :slightly_smiling_face:

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.