I would just make a DSL. 
runCoroutine {
context { Dispatchers.IO }
timeout { timeout }
runInterruptible
block {
src.inputStream().use { input ->
dest.outputStream().use { out ->
interruptibleStreamCopy(input, out)
}
}
}
}
I think Kotlin provides pretty good tools for flattening nested lambdas, without resorting to a new syntax.
I donât know, this way still feels awful to me. I think it is unnecessarily complex way of
solving a small problem. I am not defending my proposal solely because it is mine but I am
really trying to imagine how the âdecorateâ and similar proposals would be used and still feel like it is overly engineering a solution for a simple problem.
My proposal was aiming to be as simple and ânot changingâ as possible thus I guess it is to me
the better solution.
That aside. This is how to use the âdecorateâ keyword in Jetpack Compose which is the cause of the problem.
LaunchEffect(Unit) {
launch {
withContext(Dispatchers.IO) {
loadFromCache()
}
}
}
Card(modifier) {
someList.forEach { value ->
Column {
Content(value)
}
}
}
// My proposal
LaunchEffect(Unit):
launch: withContext(Dispatchers.IO):
loadFromCache()
Card(modifier): someList.forEach: value -> Column:
Content(value)
// My other proposal - without `:` to not "be like python"
LaunchEffect(Unit) ->
launch -> withContext(Dispatchers.IO) ->
loadFromCache()
Card(modifier) -> someList.forEach value -> Column:
Content(value)
// Using the "decorate" keyword
run {
decorate LaunchEffect(Unit)
decorate launch
decorate withContext(Dispatchers.IO)
loadFromCache()
}
decorate Card(modifier)
decorate someList.forEach value
decorate Column
Content(value)
See my point? just imagine if I wanted to add another someList.forEach. It would be like:
Card(modifier) {
run {
decorate someList.forEach value
decorate Column
Content(value)
}
run {
decorate someOtherList.forEach value
decorate Column
OtherContent(value)
}
}
Were my proposal would be like:
Card(modifier) {
someList.forEach: value -> Column:
Content(value)
someOtherList.forEach: value -> Column:
OtherContent(value)
}
Yes. lets make a DSL for everything and escalate the issue more and more to the degree that our jars have billions and billions of lambda classes just to cover all the nesting combinations and reduce our nesting.
Again, this issue is not relevant if Kotlin didnât have kotlin-html and Jetpack Compose. have you used those?
I think misunderstanding comes from the fact you try to solve a different kind of problem than others in this topic (and yes, I know, this is âyourâ topic). Others focus on unnecessary nesting and your proposal doesnât at all affect nesting. Yes, we can do launch: withContext(Dispatchers.IO):, but similarly we can do: launch { withContext(Dispatchers.IO) {. Itâs the same.
Correct me if I didnât get you right, but the key improvement you are looking for is to skip these noisy closing brackets, right? If yes, then hereâs the problem: I believe most Kotlin developers will prefer:
if (cond) {
doSomething()
}
over:
if (cond)
doSomething()
Even if both code samples are valid in Kotlin, most (I believe) will choose the first one. And your proposal is pretty much bringing the second syntax to higher-order function calls.
Yes, this is correct.
Outside kotlin-html and Jetpack Compose, yes I would prefer the first one indeed.
If you say soâŠ
Did you know? all the features we have been waiting for for ages are just syntax sugar for
tiny things that we can do without the syntax sugar. We can provide the last lambda inside the parenthesis and we can call the operators by function names. Why would we need âinfixâ? it is just a dot why not type it? it is the same! Why use Kotlin, we can right down in java. Why java lets go to assembly. I can rant here all day and I donât think you would get it until the feature is adopted and you try it and you will love it.
Why I am mad? because your comment is just absurd and insulting.
I am OK with criticism and I really think my proposal isnât that good. The -100 points thing I totally get and accept and I donât believe my proposal would reach 0 in the minds of everyone but criticism is different than questioning everything to the point that makes all syntax sugar seems like just laziness.
If you feel this way about my comments, then I apologize and I wonât comment your proposal anymore. I may still take part in the conversation about decorators as I find it interesting.
It is fine. Sorry. I was too dramatic about it. I was stressed out.
The decorators proposal is similar to my proposal. I will be very happy to hear what you think
about them. It is Kotlin that brought us here and it (Kotlin) becoming better and better is our
ultimate goal and the reason we discuss features here and weigh them to not introduce unnecessary features. I totally agree that my proposal my not appeal to people and I should have
being more acceptable to a wider and wilder kinds of criticism. again. Sorry <3
You could write it like this, but that wasnât my intent. My intent was:
Card(modifier) {
for (value in someList) {
decorate Column
Content(value)
}
for (value in someOtherList) {
decorate Column
OtherContent
}
}
but honestly, that example doesnât change much over the already-accepted:
Card(modifier) {
for (value in someList) Column {
Content(value)
}
for (value in someOtherList) Column {
OtherContent
}
}
Anyway, I donât think the : syntax will get accepted, if only because it changes the Kotlin syntax quite a bit, and isnât coherent with existing keywords (we donât write if (foo): for short syntax).
The other reason is that we cannot add syntax that is ambiguous, and that syntax is ambiguous: it is hard to see at a glance where the semantic blocks end.
These were examples to simplify the proposal. not everything could be simplified down to a for loop.
The : syntax could be replaced.