https://kotlinlang.org logo
#language-evolution
Title
# language-evolution
u

uli

10/14/2021, 8:09 PM
Hi all, is no one missing inline extensions on functional types? I have found a discussion from 2016! And a youtrack issue form 2018 but could not find any activity around it. Sounds almost closer to a bug then a feature request: https://discuss.kotlinlang.org/t/inline-receivers/2084 https://youtrack.jetbrains.com/issue/KT-5837 Additionally,
suspend
-edness is not inferred on functional receivers at call site.
2
I worked on some library code to handle exceptions. Here is an abstracted example of what I want to do:
Copy code
suspend fun exceptionTest() {
        suspend { // <- suspend should not be needed
            doSomeThing()
        }.logAndDropExceptions("Something failed")
    }

    protected suspend fun <T> (suspend () -> T).logAndDropExceptions(message: String) {
        try {
            this()
        } catch (e: Exception) {
            log("$message: $e")
        }
    }
I would expect receivers to behave like parameters. This includes: 1. type inference should know that the receiver is suspend without the explicit ‘fake’
suspend
keyword 2. If I make
logAndDropExceptions
inline, suspended-ness of the receiver should follow from the suspending environment of the call site and should not need any declaration at all 3. And sure I’d expect the no-overhead-benefits that we learned to expect from inline functions
It works like a charm when I turn the receiver into a parameter. But
logAndDropExceptions("Something failed")
before the block does not feel right
Copy code
suspend fun exceptionTest() {
    logAndDropExceptions("Something failed") {
        doSomeThing()
    }
}

protected inline fun <T> logAndDropExceptions(message: String, block: () -> T) {
    try {
        block()
    } catch (e: Exception) {
        log("$message: $e")
    }
}
e

ephemient

10/14/2021, 9:42 PM
receiver lambda inference in general seems to not be there;
Copy code
fun ((Int) -> Unit).f() = Unit
{ println(it) }.f()
fails to compile
u

uli

10/14/2021, 9:44 PM
what a pity
e

elizarov

10/21/2021, 4:11 PM
It is not idiomatic in Kotlin. Kotlin is not even designed for doing that. Not even in type inference. Even parsers will start to act weirdly if you do it. Don’t.
Instead of
{ … }.doSomething
design yours APIs around
doSomething { … }
, please
u

uli

11/01/2021, 3:24 PM
Hi @elizarov, you write “It is not idiomatic in Kotlin. Kotlin is not even designed for doing that”. Got it. No good idea to do that right now. Could you clarify if this has just not be taken into account as a use case during language design - then it is a topic for #language-evolution - or if there are good reasons for a language not to support such a notation. I mean, lambdas are first class objects in Kotlin and this ‘limitation’ comes a bit as a surprise. Especially with a failure string as parameter I find it a lot more readable to write
Copy code
{
    // some code
}.logAndDropExceptions("Something failed")
instead of
Copy code
logAndDropExceptions("Something failed") {
    // some code
}
And what exactly should I not do? Extensions on lambdas? Or only extensions on lambda literals?
e

elizarov

11/04/2021, 9:28 PM
Don’t do extensions on lambdas.
u

uli

11/04/2021, 9:29 PM
Ok. I guess if i have to trust someone on that it would be you :-)
But we are here on #language-evolution Do you propose it is a fact of life that extensions on lambda are a bad thing? Or more like a limitation of Kotlin’s design that is worth to undergo an evolution. After all if ‘Even parsers will start to act weirdly if you do it’ i see one of two hard bugs. 1. The parser is broken 2. The parser is not expected to be able to parse such constructs. Then the compiler should error out
e

elizarov

12/01/2021, 10:42 AM
The parser is not expected to parse
{ … }.doSomething()
since this kind of code is not expected to appear in idiomatic Kotlin. Idiomatic Kotlin is all about readability. The code shall read like prose. In order for human to read and understand this code it shall start with some introduction, setting context.
2 Views