Unintuitive use_small_heuristics

[Ekleog]

The documentation states “Whether to use different formatting for items and expressions if they satisfy a heuristic notion of 'small'.”

So my definition of “small” here is obviously subjective.

Anyway, I'd have expected rustfmt 0.4.2-nightly (dd807e2 2018-04-18) to have put the following on a single line:

             (self.code.code() % 10) as u8 + b'0',
         ];
         w.write_all(code)?;
-        w.write_all(if self.is_last == IsLastLine::Yes { b" " } else { b"-" })?;
+        w.write_all(if self.is_last == IsLastLine::Yes {
+            b" "
+        } else {
+            b"-"
+        })?;
         w.write_all(self.line)?;
         w.write_all(b"\r\n")
     }

 
 impl<'a> fmt::Debug for EhloCommand<'a> {
     fn fmt(&self, f: &mut fmt::Formatter) -> Result<(), fmt::Error> {
-        write!(f, "EhloCommand {{ domain: {:?} }}", bytes_to_dbg(self.domain))
+        write!(
+            f,
+            "EhloCommand {{ domain: {:?} }}",
+            bytes_to_dbg(self.domain)
+        )
     }
 }
 

         } else {
-            Ok(Reply { code, is_last, line })
+            Ok(Reply {
+                code,
+                is_last,
+                line,
+            })
         }

Then maybe my definition of “small line” is not the same as the one of other people, so maybe an option for tweaking the “sensitivity” of the smallness heuristic could help here?

[nrc]

'small' is deliberately set to be very small because we believe that the readability benefit of using more vertical space usually outweighs any benefit of keeping things on one line. For example, for struct literals, the use case for small is something like Point { x, y }. It is possible we'll tweak these things a bit in the future, but we'll probably still err on the side of too small rather than too big.

Because the small heuristic affects quite a few variables, adding sensitivity options is complex. I do intend to do it, but not in the near future (at least not before a 1.0 release).

[Ekleog]

OK thanks! A 1.0 release is more important than this, indeed :)

[nickolay]

I tried to figure out the status of this problem, and as far as I understood:

• The Rust Style Guide says "We leave it to individual tools to decide on exactly what small means" following the discussion in Define 'short' style-team#47, where there was an attempt to define "small" in general, that was eventually given up to "[allow] implementations to incrementally improve their design".
• rustfmt currently has a number of number-of-characters constants in WidthHeuristics, e.g. "[struct_lit_width is the] Maximum width in the body of a struct lit before falling back to vertical formatting".
  • Initially configurable independently, they are now controlled by a single use_small_heuristics option (note Bring back longer lines #2437 about the problems with that).
  • When the heuristics are on, the number-of-columns options are set based on max_width (e.g. struct_lit_width = 18% * max_width), which may be unintuitive when something you deem "very simple" is split across multiple lines.

I didn't find any plans regarding improving the heuristics though, and I think that trying to incrementally define "simple" for the specific obvious cases (such as the StructLiteral {with, shorthands, only} - the last example in this issue) has the highest chance of improving the status quo. @nrc, what do you think?

[nrc]

One issue is that we have a backwards compatibility guarantee and changing the heuristics would break that. So either this would have to be opt-in and/or it would need a 2.0 release. That means the Rustfmt team should absolutely be sure that it is worth working on and plan out exactly when they want to do that.

I think we probably could do better than the existing heuristics, and it would be good to do so. So It think it is worth experimenting with better heuristics. However, I also think there are quite a few other things which ought to be higher priority.