Generic Run Analogues #218
Conversation
There was a problem hiding this comment.
Why treat the receiver in a special way like this? We can resolve parameters already, and the name of a parameter can be some special this object. Does this function add much?
There was a problem hiding this comment.
I did it to avoid too many SpecialNames.THIS calls. Besides, the implementation for non-inline parameters is a little bit different.
I think I will need such function but with parameters in the upcoming PRs to find a proper receiver.
It turns out that explicit this in Kotlin can only refer to the innermost scope (with receiver argument), but implicit "this" may come from anywhere. With parameters the situation is different.
...rification/formver.core/src/org/jetbrains/kotlin/formver/conversion/StmtConversionVisitor.kt
Outdated
Show resolved
Hide resolved
|
The thing that concerns me here is that we are collapsing two different notions (dispatch receiver and extension receiver) into one. Maybe if we're working on this anyway, it would be best if we supported both? Or is there some technical reason why this would be much harder? |
@jesyspa, well, in this case we would need to distinguish possible implicit receivers already. |
|
Let's have a call about this on Monday, I'm not entirely against doing it this way but it seems risky. |
With this pull request functions analogous to Kotlin `run` successfully compile to Viper if they're inline. For instance, call to ```inline fun <T, R> T.copiedRun(block: T.() -> R): R = block()``` will be correctly inlined. Support for real stdlib `run` and other notable extension functions (`also`, `let` etc.) as well as the cases with multiple possible receivers will be implemented in future PRs.
With this pull request functions analogous to Kotlin `run` successfully compile to Viper if they're inline. For instance, call to ```inline fun <T, R> T.copiedRun(block: T.() -> R): R = block()``` will be correctly inlined. Support for real stdlib `run` and other notable extension functions (`also`, `let` etc.) as well as the cases with multiple possible receivers will be implemented in future PRs.
With this pull request functions analogous to Kotlin `run` successfully compile to Viper if they're inline. For instance, call to ```inline fun <T, R> T.copiedRun(block: T.() -> R): R = block()``` will be correctly inlined. Support for real stdlib `run` and other notable extension functions (`also`, `let` etc.) as well as the cases with multiple possible receivers will be implemented in future PRs.
With this pull request functions analogous to Kotlin `run` successfully compile to Viper if they're inline. For instance, call to ```inline fun <T, R> T.copiedRun(block: T.() -> R): R = block()``` will be correctly inlined. Support for real stdlib `run` and other notable extension functions (`also`, `let` etc.) as well as the cases with multiple possible receivers will be implemented in future PRs.
With this pull request functions analogous to Kotlin
runsuccessfully compile to Viper if they're inline.For instance, call to
inline fun <T, R> T.copiedRun(block: T.() -> R): R = block()will be correctly inlined.
Support for real stdlib
runand other notable extension functions (also,letetc.) as well as the cases with multiple possible receivers will be implemented in future PRs.