[unstable option] blank_lines_lower_bound

[scampi]

Tracking issue for blank_lines_lower_bound

[Boscop]

It would be more useful if statements inside functions are not covered by this, only declarations!

Or is there another way to specify that I want to have at least 1 empty line between declarations (also between function-local declarations and whatever comes before/after)? (But not between statements in a function body.)

Example
Original Code (rustfmt will not change it with the default value of 0):

const A: u32 = 1;
enum B {
	C
}
impl B {
	// ...
}

Set to 1:

const A: u32 = 1;

enum B {
	C
}

impl B {
	// ...
}

[lunacookies]

What are the issues blocking the stabilisation of this option?

[calebcartwright]

@arzg - The process and requirements for stabilizing a configuration option are described here. Specifically, there are several issues that exist with blank_lines_lower_bound in released versions of rustfmt (1.x versions), for example #2954.

Some fixes/improvements to blank_lines_lower_bound have been made within the rustfmt source, but they have not yet been released. As such there are at least two stabilization requirements not yet for this configuration option:

• The design and implementation of the option are sound and clean.
• The option is well tested, both in unit tests and, optimally, in real usage.

[Systemcluster]

With blank_lines_lower_bound set to 0, rustfmt (1.4.27-nightly (580d826e 2020-11-16)) will still insert blank lines between fns, for example

impl A {
    fn a() { /* ... */ }
    fn b() { /* ... */ }
}

will get formatted to

impl A {
    fn a() { /* ... */ }

    fn b() { /* ... */ }
}

Is this correct? I.e., should this case be covered by this configuration option?

[nrc]

It would be nice to have slightly more finegrained control with this option, in particular, I would like to allow items which fit on a single line to have a 0 value, but larger items to have a 1 value.

[bluss]

This option doesn't seem to have a useful behaviour at the moment, is it something that will be tweaked?

My expectation would be that items (functions, struct definitions, similar) are separated by the lines (the documentation says items).

What actually happens is that attributes are spaced with one line before their functions, statements by one line etc, doc comments by one line before their functions etc. (Using blank_lines_lower_bound = 1 rustfmt 1.4.37-nightly (0bd2b19 2021-04-03)

@@ -1460,6 +1490,7 @@ impl<A> Clone for OwnedArcRepr<A> {
 /// [`RawArrayView`](type.RawArrayView.html) /
 /// [`RawArrayViewMut`](type.RawArrayViewMut.html) for the array type!*
 #[derive(Copy, Clone)]
+
 // This is just a marker type, to carry the mutability and element type.
 pub struct RawViewRepr<A> {
     ptr: PhantomData<A>,
@@ -1467,7 +1498,9 @@ pub struct RawViewRepr<A> {
 
 impl<A> RawViewRepr<A> {
     #[inline(always)]
+
     fn new() -> Self {
+
         RawViewRepr { ptr: PhantomData }
     }
 }
@@ -1620,6 +1686,8 @@ mod impl_raw_views;
 mod impl_cow;
 
 /// Returns `true` if the pointer is aligned.
+
 pub(crate) fn is_aligned<T>(ptr: *const T) -> bool {
+
     (ptr as usize) % ::std::mem::align_of::<T>() == 0
 }

[calebcartwright]

This option doesn't seem to have a useful behaviour at the moment, is it something that will be tweaked?

@bluss - your snippets are related to a bug (#2954) that's been fixed in source but not included yet in a release, it will (at a minimum) be corrected to only ensure spacing between items

[Keavon]

Hello, would it be possible to please get a update on the status of this being stabilized? Thank you very much.

[dcow]

When

This option doesn't seem to have a useful behaviour at the moment, is it something that will be tweaked?

@bluss - your snippets are related to a bug (#2954) that's been fixed in source but not included yet in a release, it will (at a minimum) be corrected to only ensure spacing between items

I am still experiencing this bug.

[ytmimi]

@dcow I'd suggest that you open up a new issue to fully describe the problem that you're experiencing

[sezna]

I just finished reading the saga over here about newlines between definitions etc., and then found the implementation and ultimately this tracking issue. It seems like originally the consensus was to allow for configurability in whitespace between both statements and items. I understand this to mean configuration for statements, and configuration for items. But the implementation currently provides one option for both statements and items. As @bluss pointed out above, this is not particularly useful behavior.

I would say it is pretty common that teams want blank newlines between function definitions, but uncommon that teams want blank newlines between every single statement in a function. I don't see any discussion between the issue I linked above and the implementation, though, so I'm not sure how this new merged-configuration implementation was decided upon. Is there any other discussion I am missing, perhaps?

Also, thanks for all the work up until this point. Obviously the tool is great and I'm happy that the discussion has made it this far. I am just seeking clarity on what happened, and if it is still planned to add configurability for spaces between definitions.

[dxps]

I would say it is pretty common that teams want blank newlines between function definitions

Yes, that would be preferrable, as some functions signature becomes readable when a new blank line within the function body exists.

[azizur]

I am new to Rust world. The fact that it's over 5 years since issue was raised. I am thinking this project has been abandoned?

[calebcartwright]

I am new to Rust world.

Welcome 👋

The fact that it's over 5 years since issue was raised. I am thinking this project has been abandoned?

No, and I'd suggest that using the amount of time that has passed since any given issue was opened as a measure for whether a project is active vs. abandoned is not going to lead to accurate results.

I don't think there's any singular way to adequately gauge a project's health, but I think some better indicators would be things like whether maintainers are responding, whether there are some issues being opened/triaged/closed, (in some cases) whether there's still code changes being made, bugs being fixed/features being added, etc.

I'd posit that if you go look at most large-scale projects on GitHub you'll find they have open issues that are much, much older than 5 years!