chain-method-continution should take priority over argument-list-wrapping

[mklnwt]

chain-method-continution should take priority over argument-list-wrapping.

// Assume that the last
// allowed character is
// at the X character
// on the right             X
val foo = Bar.builder().baz(1).build()

Expected Rule behavior

val foo = Bar.builder()
    .baz(1)
    .build()

Current Behavior

val foo = Bar
    .builder()
    .baz(
        1,
    ).build()

Additional information

• Current version of ktlint: 1.1.0

[paul-dingemans]

I am not sure what the best order of those 2 rules is. Given code below:

                val foo1 = requireNotNull(bar.filter { it == "bar" }) { "some message" }
                val foo2 = requireNotNull(bar?.filter { it == "bar" }) { "some message" }

the expected outcome is:

                val foo1 = requireNotNull(
                    bar.filter { it == "bar" }
                ) { "some message" }
                val foo2 = requireNotNull(
                    bar?.filter { it == "bar" }
                ) { "some message" }

We need some smarter algorith do decide which rule takes precedence. But most like it will be hard to implement that without having breaking changes in the KtlintRuleEngine.

[mklnwt]

Best way would probably to check whether the chained call is within an argument or not.

Otherwise I agree, this could get very complex.

Would it be possible for an initial precedence to check if the parent of the chain is an assignment or a block.
Yes -> precedence
Not -> argument comes first

[paul-dingemans]

Would it be possible for an initial precedence to check if the parent of the chain is an assignment or a block.
Yes -> precedence
Not -> argument comes first

The order of the rules is defined before scanning starts. When you run ktlint CLI with --log-level=debug the order of the rules is printed.

Another complication is that a rule is not aware whether other rules are loaded or not (except when a rule has a declared dependency on another rule). If this information was available, the argument-list-wrapping rule could check if chain-method-continuation is enabled and take that into account when deciding to wrap the arguments in a method chain. This however is a breaking API change, and has to wait until Ktlint 2.0 is released (which might take a long time).