Preserving user-authored line breaks produces non-deterministic output for equivalent syntax trees

[c1rcle]

While I do agree with the points raised in #547, I'm not a fan of the approach that was ultimately chosen. Preserving user-authored line breaks inside lambdas violates the deterministic premise this formatter was arguably built upon. The most appealing principle for me was that any equivalent input syntax tree would always result in the same formatted output (barring any additional newlines in function bodies). This is not the case anymore, as developers may influence the formatting result in lambdas, which aren't only used for DSLs.

Could this have been approached differently? How about wrapping the outer lambda body to a new line if it contains a nested lambda on the very same line? To be clear, I'm not suggesting that "preserve user-authored line breaks" should be completely removed or replaced - I just don't think it should have been made the default.

[qwwdfsad]

Note: we are reconsidering the kotlinlang codestyle as well as some defaults there (with the intention to make it a default at some point).

Could this have been approached differently?

That's something we are experimenting with!
When looking at what people like and dislike about ktfmt output (as well as running a quick watercooler poll), it seems like there are three main patterns (involving user-defined linebreaks) that we want to address:

• Nested lambdas like in Reconsider lambda single-lining for Jetpack Compose #547
• Arguments layout (i.e. for explicitly-named arguments, sometimes it's much more desirable to have one argument per line)
• Line break after = for ifs and whens

I am not 100% positive that we'll be able to keep the full determinism for these patterns, but for lambdas we are experimenting.

How about wrapping the outer lambda body to a new line if it contains a nested lambda on the very same line?

Might be it, or maybe we should require it if and only if there is an explicit receiver.
Then Button { Text("") } will break but things like listOfStrings.flatMap { it.split(" ") } won't.
Not sure about the desired behaviour for flatMap { x -> map { y -> x to y } } though.

In a nutshell, it seems like we are trying to syntactically guess whether the snippet is DSL or a call chain. If we succeed with a minimal collateral damage -- nice. If we don't, we'll have to preserve some line breaks