Good points. And this is a great explanation of how this proposal differs from with context
.
I think a single flattened closure with brackets would be the balanced counter if something were to be added. Having at least one closure avoids throwing in magic into all the following lines and hiding the fact that they cannot be considered equal with the code above the entry to the closure.
Maybe something closer to the chained lambda calls make more sense if it’s important to keep the distinction of code that’s outside vs inside the closures.
use(MyResource()) -> transaction() -> withTimeout(5000) -> {
// code
}
// Or typed on multiple lines
use(MyResource()) ->
withTimeout(5000) ->
transaction() -> {
// code
}
^ Not that I’m super keen on that yet either. I can spot a few issues with return types–just brainstorming.
The downside is that this drops the ability of the OP proposal to run code between the layers. I wonder if that’s not as important depending on the IRL use cases? It might be worth pulling up the chained lambda discussions and seeing what ideas those landed on.
Still, I suspect contexts will have a larger impact on these use cases and I’m curious to see what options people come up.
EDIT: Here’s a link to one discussion on simplifying nested lambda’s: More concise nested lambdas - #2 by broot