Not sure where to ask for this but... In gradle (kts) can the `sourceSets` function's receiver be ch...

# multiplatform

[Dominaezzz]

Not sure where to ask for this but...
In gradle (kts) can the sourceSets function's receiver be changed from NamedDomainObjectContainer<KotlinSourceSet> to NamedDomainObjectContainerScope<KotlinSourceSet>? (Or just delete the function altogether since the object is available)
It allows for "commonMain" { } also, instead of just val commonMain by getting { }.

[Dominaezzz]

I'm currently having to do sourceSets.invoke { }.

[gildor]

Yes, invoke {} is correct way to get scope

[gildor]

But are you sure that you need "commonMain"? Type safe accessor should be available for it already

[Dominaezzz]

omg when was that added?!

[Dominaezzz]

Thanks btw

[gildor]

It was not added, Kotlin DSL generates type safe accessors if this element of NamedDomainObjectContainer is available on configuration time

[gildor]

You even can create own plugin (in buildSrc for example), add required platforms and type safe accessors fo them also will be generated and you can use them if applied your custom plugin

[Dominaezzz]

I realise I can do that but it's something most people would be doing on multiplatform though, so it might as well be in the main plugin.

[Dominaezzz]

Why is invoke the correct way to get scope?

[gildor]

It cannot be added in the main plugin, because it wouldn't be type safe, you have source set only when you add related target platform

[Dominaezzz]

It's a bit awkward to call an operator directly.

[gildor]

By default sourceSet {} should work

[gildor]

But in some cases, resolution order will not call invoke

[Dominaezzz]

The receiver is different sadly.

[gildor]

I would just use named("something") it lazy, not something really important, just good style to use lazy configurations everywhete

[gildor]

I abandoned invoke syntax long time ago (except for dependency configurations) and have no problems with scope and always explicit about config, should it be added (register) or retrieve existing one (named)

[gildor]

And use type-safe accessors when it's possible

[gildor]

@Dominaezzz see this issue
https://youtrack.jetbrains.com/issue/KT-15711

[Dominaezzz]

I'm refactoring my scripts towards laziness and type safety, so this is very useful, thanks! (currently stuck on kts script plugins though).

[gildor]

On script plugins? I wouldn't recommend to use them, maybe only as transition step from groovy (in this case they are very useful)

[gildor]

Instead would use precompiled script plugins