-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic Run Analogues #218
Generic Run Analogues #218
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.