Disable implicit resolution to receivers of outer scopes


#1

I have posted a topic here, but nobody has answered my question yet. To make it simple, I am asking if there is a way to disable implicit resolution to the “this” receivers in outer scopes. Is it possible to have the implicit “this” receiver resolution applies only to the current inner-most scope? For example,

div {
    div {
        + "It is okay to embed a div here nested inside a div."
    }
    p {
        + "This is a p element paragraph"
        div {
            + "This should not be allowed because a p element cannot embed a div element! "
            + "This div element is actually added to the outer div element, and is actually a programming mistake."
        }
    }
}

I cannot make sure that the “div” method cannot be called inside a p{} lambda even if the receiver type of the p{} lambda does not support a “div” method call, because it will be mistakenly resolved by the compiler to the “div” method of the receiver of the outer div{} lambda because receiver type of div{} lambda must support “div” method call in order to allow nested “div” elements.

This causes a problem that I cannot design a good DSL builder to ensure strict semantic and syntactic correctness in certain situations.

Can I suggest an option in the Kotlin compiler to disable implicit outer scope receiver resolution? Implicit receiver resolution can only be applied to the current inner most scope that has a receiver. Programmers can always resort to use explicit receiver resolution using this@label to refer to receivers in the outer scopes.

Regards,
VN


#2

The problem has been discussed many times over the years, and we definitely plan to address it. However, adding a compiler option would not be an appropriate solution for this. Instead, you, as a DSL writer, will be able to specify a modifier for a parameter accepting a lambda with receiver which will narrow down the resolution scope inside that lambda.

The YouTrack issue tracking this problem is https://youtrack.jetbrains.com/issue/KT-11551


#3

Thanks for your reply! Looking forward to the solution.

Regards,
VN


#4

Here’s the draft design proposal: https://github.com/Kotlin/KEEP/pull/38