Channels
#language-evolution
Title
# language-evolution
u
uli
10/14/2021, 8:09 PMHi 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➕ 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")
}
}suspendlogAndDropExceptionsIt works like a charm when I turn the receiver into a parameter. But
logAndDropExceptions("Something failed") 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 PMreceiver lambda inference in general seems to not be there;
Copy code
fun ((Int) -> Unit).f() = Unit
{ println(it) }.f()u
uli
10/14/2021, 9:44 PMwhat a pity
e
elizarov
10/21/2021, 4:11 PMIt 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
{ … }.doSomethingdoSomething { … }u
uli
11/01/2021, 3:24 PMHi @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") 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 PMDon’t do extensions on lambdas.
u
uli
11/04/2021, 9:29 PMOk. 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 AMThe parser is not expected to parse
{ … }.doSomething()2 Views