Is there a specific reason to use Gradle properties for things like `kotlin.mpp.stability.nowarn` , ...

# gradle

[mbonnin]

Is there a specific reason to use Gradle properties for things like kotlin.mpp.stability.nowarn , kotlin.native.binary.memoryModel or kotlin.stdlib.default.dependency ? I'd love these to be moved to setters/getters APIs in the "kotlin" extension instead:
1. that'd allow proper API lifecycle management (preview, stable, deprecated) and avoid cluttering the gradle.properties file with properties that are not supported any more
2. that can be more precise about when the property is needed. I understand something like kotlin.native.binary.memoryModel is only for binaries so adding it only in binaries {} makes this explicit compared to a global gradle.properties prop
3. Maybe it'll play better with Gradle configuration cache?

[Big Chungus]

Why not both? Have DSL exposed and default to property if not set

[Big Chungus]

(at least that's what I do with my plugins, not sure what caching/performance implications are there, though)

[mbonnin]

The issue with "both" is that it scatters documentation

[mbonnin]

And I mainly see downsides to the gradle.properties approach. One upside is that it's somewhat "easier" to copy/paste something in gradle.properties but even that could be argued given that it comes with a cost

[mbonnin]

kotlin.native.binary.memoryModel supports both but everyone uses the gradle.properties version because it's everywhere in the docs

[Big Chungus]

I personally LOVE gradle.properties as it makes overriding things in CI or making project templates a breeze. I do agree that properties being the only option is worse than DSL, but surely having both exposed is not a big ask.

[tapchicoma]

@mbonnin please open a new Kotlin issue

[mbonnin]

https://youtrack.jetbrains.com/issue/KT-50552

[El Zhang]

I completely support using DSL instead of properties. Properties find its place for custom env arguments for per build env, while using in gradle plugins may be a little confusing without doc.

[ilya.gorbunov]

Sometimes the decision on how to configure something must be made during the plugin application. Configuring values through the extension might be too late in that case.

[mbonnin]

@ilya.gorbunov aahh the Gradle lifecycle
.. I'd argue that this could be changed by doing more things lazily but yea Gradle doesn't make this easy...