Thread
#language-evolution
    uli

    uli

    11 months ago
    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.
    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
    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")
        }
    }
    e

    ephemient

    11 months ago
    receiver lambda inference in general seems to not be there;
    fun ((Int) -> Unit).f() = Unit
    { println(it) }.f()
    fails to compile
    uli

    uli

    11 months ago
    what a pity
    elizarov

    elizarov

    11 months ago
    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
    uli

    uli

    10 months ago
    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
    }
    And what exactly should I not do? Extensions on lambdas? Or only extensions on lambda literals?
    elizarov

    elizarov

    10 months ago
    Don’t do extensions on lambdas.
    uli

    uli

    10 months ago
    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
    elizarov

    elizarov

    9 months ago
    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.