Stop enforcing a space in empty containers?

[DavHau]

Input

{
  attrs = {};
  lists = [];
}

Output

{
  attrs = { };
  lists = [ ];
}

Desired output

see input

Opinion

I don't see what benefit comes by enforcing a space inside empty attrsets and lists.
It doesn't simplify editing workflow.
It doesn't increase readability.

I personally prefer not to put a space in there.

If others agree that there are no advantages/disadvantages in this, then this should probably be disabled, as it unnecessarily produces changes in files, which otherwise wouldn't require re-formatting.

Related:
#185: This is not a conflicting issue. If the coder decides to put a space it containers, it is fine as well and doesn't need to be re-formatted.

[r-burns]

Even putting personal preference aside, from a purely descriptivist standpoint no-space appears to be the predominant style in Nixpkgs:

$ cd nixpkgs

$ rg '\[ \]' | wc -l
2797

$ rg '\[\]' | wc -l
11617

$ rg '\{ \}' | wc -l
16714

$ rg '\{\}' | wc -l
23533

[zimbatm]

When we wrote the rule my impression was that the space was predominant. We should adopt whatever style is predominant in nixpkgs.

[DavHau]

We should adopt whatever style is predominant in nixpkgs.

Does that mean you prefer adopting predominant style over good/useful style?

Some of the stuff which is predominant right now is not good and negatively impacts editing workflow / git diffs etc., see for example: #248

If the ultimate goal is to establish a standard that is going to be enforced at some point in the future, shouldn't the first priority be to make that standard good and useful instead of adopting what is predominant right now?

For the current issue, I suggest that we just allow both styles (containers with and without space), because it really doesn't matter if there is a space or not. Maybe limiting the number of spaces to 1 could make sense.

[mohe2015]

I think no space also has the advantage that it takes less horizontal space. And probably (but this is highly unscientific) your brain has it easier to parse it as its kind of "one token"

[kamadorueda]

Proposed implementation: #280

[zimbatm]

Does that mean you prefer adopting predominant style over good/useful style?

It depends on how clear the improvement is. For example, here it could make things less consistent:

{
   listA = [];
   listB = [ 1 2 3 ];
}

vs

{
   listA = [ ];
   listB = [ 1 2 3 ];
}

In the second case, the whitespace is always present. To me, that seems like a simpler rule. I think most people are used to no spaces at all, in both listA and listB, coming from other languages and so would more readily adopt the first list.

It feels a bit nit-picky either way and I'm ready to change my mind. My only concern is that we aren't really representative of the community as a whole. That's when I think we should default to whatever is the most common. @r-burns showed that the no space is more common for empty lists so I guess we can go down that route.

[kamadorueda]

Some people see a formatter as a way to make code more beautiful, but beauty is subjective

So my perspective of a formatter is that it's a tool that avoid discussions of style A vs style B and standardizes code,
so people can focus on the soul of the software instead of its skin

To me, having a rule, even if ugly to some people (again, ugliness is subjective)
is more valuable than not having a rule