Strange formatting for lambda with chained function call

[kyay10]

The formatter considers the following as properly formatted:
(kotlinlang-style)

fun quux() =
    runnnnn {
            foo()
            bar()
        }
        .baz()

(Java-like)

fun quux() =
    runnnnn {
          foo()
          bar()
        }
        .baz()

It seems to be adding a continuation indentation to the ending brace and the content of the lambda
Is this intentional behaviour? It looks really strange to me, personally.
It happens without the single-expression body as well:

fun quux() {
    runnnnn {
            foo()
            bar()
        }
        .baz()
}

What I'd prefer instead is this:

fun quux() {
    runnnnn {
        foo()
        bar()
    }.baz()
}

i.e. the ending brace should always have the same indentation as the starting brace, and thus the lambda should always have block indentation, and nothing more. For the .baz() call, I'm fine with whatever. It can be on a separate line, or the same line, or floating, or anything like that. I just dislike the idea that lambdas float in such a strange way.
For what it's worth, try-catch handles this elegantly IMO:

fun quux() {
    try {
        foo()
        bar()
    } catch (_: Throwable) {
        foo()
        bar()
    }
}

fun quux() {
    try {
        foo()
        bar()
    } catch (_: Throwable) {}
}

and similarly with infix calls and operators:

fun quux() {
    runnnnnn {
        foo()
        bar()
    } + baz()
}

fun quux() {
    runnnnnn {
        foo()
        bar()
    } inny baz()
}

so I'd call this "precedent"

[greyhairredbear]

How do you think a call chain should be formatted when having another call after baz()

fun quux() {
    runnnnn {
        foo()
        bar()
    }.baz()
    .bazinga()
}

fun quux() {
    runnnnn {
        foo()
        bar()
    }.baz()
        .bazinga()
}

fun quux() {
    runnnnn {
        foo()
        bar()
    }
    .baz()
    .bazinga()
}

fun quux() {
    runnnnn {
        foo()
        bar()
    }
        .baz()
        .bazinga()
}

5. something else

An output for a + operator I got with IntelliJ Plugin 1.3.0.61 (not sure why the version has 4 numbers though) for reference:

fun main() {
  when (42) {
    else -> 1
  } +
      veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFunctionName() +
      veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFunctionName()
}

fun veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFunctionName(): Int {
  return 41893798
}

I suppose the "equivalent" would be 4)

[rock3r]

I'd say 3 or 4 seem the most natural (for example, ktlint does 4).

[urmichm]

@greyhairredbear @rock3r
would you say 3 better compared to 4? ktlint can do what they do :)

[rock3r]

I don't have a strong preference, either works for me as long as they're consistent

[greyhairredbear]

Personally, I'd go with 4)

• more consistent with existing behavior (see my previous comment)
• a call chain gets another level of indentation

That being said, I'd generally try to avoid code like this as much as possible by extracting the first lambda/block (i.e. runnnn or when) to something else (local val, separate function) and then start a call chain from there.

[kyay10]

That being said, I'd generally try to avoid code like this as much as possible by extracting the first lambda/block (i.e. runnnn or when) to something else (local val, separate function) and then start a call chain from there.

I understand your position, and I'd tend to agree, except in cases where there's a DSL going on. It doesn't make much sense to store some of these intermediate values. In fact, for some DSLs, that can be very error-prone, since then one may reuse a value that isn't meant to be reused

[greyhairredbear]

In fact, for some DSLs, that can be very error-prone, since then one may reuse a value that isn't meant to be reused

That's when you might consider working around this by just extracting it to a function instead of a local val.

But I understand there might be cases when using DSLs, and the formatter should produce well structured output for this.