Hi all, is no one missing inline extensions on fun...

# language-evolution

[uli]

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.

[uli]

I worked on some library code to handle exceptions. Here is an abstracted example of what I want to do:

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

[uli]

It works like a charm when I turn the receiver into a parameter. But logAndDropExceptions("Something failed") before the block does not feel right

suspend fun exceptionTest() {
    logAndDropExceptions("Something failed") {
        doSomeThing()
    }
}

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

[ephemient]

receiver lambda inference in general seems to not be there;

fun ((Int) -> Unit).f() = Unit
{ println(it) }.f()

fails to compile

[uli]

what a pity

[elizarov]

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.

[elizarov]

Instead of { … }.doSomething design yours APIs around doSomething { … }, please

[uli]

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

{
    // some code
}.logAndDropExceptions("Something failed")

instead of

logAndDropExceptions("Something failed") {
    // some code
}

[uli]

And what exactly should I not do? Extensions on lambdas? Or only extensions on lambda literals?

[elizarov]

Don’t do extensions on lambdas.

[uli]

Ok. I guess if i have to trust someone on that it would be you :-)

[uli]

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

[elizarov]

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.