Rustfmt: Limit chain length by number of calls as well as width

[vorner]

Hello

I like to split my chains when they seem „complex enough“. That doesn't necessarily mean they are long in number of characters, but number of calls is a good indicator.

Eg. this still fits the width, but it's already hard to read due to too many chained calls on the same line:

self.0.take_action(Log).result().map_err(|()| LoggerError)

However, when split into multiple lines, it is easier, because the lines naturally invoke sequential thinking about what happens next.

Is it possible to have a complexity heuristic in addition to width heuristic for small items? And consider it large if it fails either?

[BurntSushi]

I've run into this sort of thing as well. Instead of heuristics, is it possible to permit the human to decide here? That is, if a chain is formatted across multiple lines by a human, then rustfmt could opt not to collapse it into a single line (if it otherwise would). I don't know if this sort of thing is a viable strategy though!

[nrc]

if a chain is formatted across multiple lines by a human, then rustfmt could opt not to collapse it into a single line (if it otherwise would)

We've tried to avoid letting the formatting of the original file affect the output formatting. We found that it led to lots of problems - it can lead to non-idempotence of output and if the input is not formatted at all then it can lead to ugly formatting

[oxalica]

What's the status of this issue?

I'm writing a HTTP client using chains, and rustfmt collapses the operations into one single line, which make it not clear enough.

I think at least it need to be configurable. (something like max_chain_calls_single_line)

Before:

pub fn delete_upload_session(&self, sess: &UploadSession) -> Result<()> {
    self.client
        .delete(&sess.upload_url)
        .send()?
        .parse_empty()
}

After (current version):

pub fn delete_upload_session(&self, sess: &UploadSession) -> Result<()> {
    self.client.delete(&sess.upload_url).send()?.parse_empty()
}

[iopq]

Mine is also very simple:

    let n: i32 = std::env::args()
        .nth(1)
        .map(parse)
        .unwrap_or(Ok(100))?;

I think I'd go with "third call is too much"

[synek317]

Any news regarding this issue?
Does it wait for a decision or just an implemention? Or maybe someone already works on it?

[zskamljic]

I am really bothered by this, assuming the input is:

let contents = fs::read_to_string(config.filename)
    .expect("Something went wrong reading the file");

or even:

let contents = fs::read_to_string(config.filename).expect("Something went wrong reading the file");

the lines would be formatted as following:

let contents =
    fs::read_to_string(config.filename).expect("Something went wrong reading the file");