I've changed `ktlint_function_signature_body_expre...

# ktlint

[David Kubecka]

I've changed ktlint_function_signature_body_expression_wrapping to multiline (from the default) and I'm seeing enclosed diff. According to the docs I would expect that the original formatting complies to the multiline setting. ktlint version=1.2.1

[Paul Dingemans]

This is a specific tweak in case the function does not have an explicit return type.

[David Kubecka]

I guess there's no way to circumvent this.

[Paul Dingemans]

Adding the return type would circumvent it. But I would not do that myself just to get the formatting that I want.

[David Kubecka]

Honestly, I don't get the logic behind the no-explicit-return-type condition. In some case such as mine I probably see the reason (the implicit type is highlighted by this formatting) but in other cases of complex scope function usage it might not be very helpful:

fun test(
  param: X
) = getList().let {
  it.converToMap()
}

[Paul Dingemans]

As far as I know there is no advise to use or not to use return types. So I would add them in case they add clarity, but in all other case I omit them. Ktlint does not enforce either.

[David Kubecka]

But do I understand it correctly that this specific tweak you are talking about tries to visually suggest the implicit type?

[Paul Dingemans]

I don't get what you mean. The function signature prevents wrapping of the multiline expression whenever it has no explicit return type. You could prevent this wrapping by adding the return type, but I would not do so myself only to get the formatting that I want.

[David Kubecka]

I'm asking why there is this special case for the function without explicit return type.

[Paul Dingemans]

Ah I see. The newline does not add clarity in this situation as the indentation of the body expression is equal or greater than the length of the previous line. I am aware that it is subjective whether it is more or less clear. But there are more constructs in Kotlin / Ktlint where the formatting takes advantage of the standard indent length of 4 spaces. One example that comes to mind is a multiline if condition where the operators nicely aligns with the parenthesis around the condition:

if (someCondition ||
    someOtherCondition
   ) {
}

for which some users argue that it should have been written as:

if (
    someCondition ||
    someOtherCondition
   ) {
}

[David Kubecka]

Perhaps my biggest problem with the current behaviour is that the expression "entry point" is visually on the same horizontal (or actually might be to the left in case of smaller indent) as the rest of the expression lines. I would rather always have the entry point horizontally aligned with the closing parenthesis - no exceptions.

Note the both your "if" examples honor this (closing parenthesis) rule from my PoV it's actually unrelated.

[Paul Dingemans]

Perhaps my biggest problem with the current behaviour is that the expression "entry point" is visually on the same horizontal (or actually might be to the left in case of smaller indent) as the rest of the expression lines. I would rather always have the entry point horizontally aligned with the closing parenthesis - no exceptions.

Please use code sample to clarify what you mean. English is not my first language, and I have the feeling that I miss important nuances which makes this discussion hard.

If you prefer to use style below, then use always as value for ktlint_function_signature_body_expression_wrapping

fun test(
  param: X
) =
    getList().let {
       it.converToMap()
    }

[David Kubecka]

I'm still speaking about my original example. The diff I'm showing is from the preferred (red) version to the current (green) version.

[David Kubecka]

If you prefer to use style below, then use always as value for ktlint_function_signature_body_expression_wrapping

I never said so 🙂 I would still like simple oneliners to stay on a single line. I'm really just talking about the complex example as shown in the first post of this thread. AFAIK the closest expression of what I would want is "handle function signatures with explicit/implicit types the same", i.e. the same as the current implicit types.