I'm a big fan of removing redundant parentheses. I believe it makes the intentional parentheses more meaningful when the reader knows they are meaningful, and it reduces noise.

Although, we can see in this example, that sometimes parentheses can be used to influence formatting (also seen in the nixos/lib/systemd-lib.nix example).

Another time where clarifying parentheses can be useful, is when applying an or expression as a function argument, or including an or expression as an item in a list literal.

Technically foo bar.baz or null is the same as foo (bar.baz or null) and the parentheses are redundant. However, since or is (the only?) example where having whitespace in an expression doesn't delimitate applied arguments, I think most readers find they add a lot of clarity in this very specific scenario.

The same is true for list literals, where [ foo.bar or "baz" ] is actually a singleton list (equivalent to [ (foo.bar or "baz") ]), despite many thinking it looks like a three item list due to the whitespace.

Note that unlike or, ? cannot be used without parentheses:

nix-repl> [ {} ? foo ]
error: syntax error, unexpected '?'
       at «string»:1:6:
            1| [ {} ? foo ]
             |      ^

nix-repl> [ ({} ? foo) ]
[ false ]

nix-repl> [ {}.foo or null ]
[ null ]

Does the linting rule make an exception for clarifying or expressions? Or perhaps there may even be a linting rule to enforce clarifying parentheses around or expressions applied as function arguments or list elements?

(maybe this is more a question for upstream, or I should stop being lazy and go RTFM read the upstream docs)

I asked myself the same questions that you did here and then concluded: The whole "redundant parentheses" is mostly a question of making the code more readable... which is not really a thing for the linter to worry about. I think the formatter should take care of that, thus I had opened NixOS/nixfmt#330. I also found NixOS/nixfmt#251, which is exactly the scenario you're describing as well.

In general, I think nixfmt should establish clear rules on when syntactically redundant parentheses are either added or removed - consistently.

And no, the upstream linter only has a single rule about that to warn about these - I think we should essentially disable this, when nixfmt can do it.

All of these thoughts came after I had already worked on a few of these parentheses, so just left the commits in here for now - also a good base to start discussion with.

Based on the discussion in NixOS/nixfmt#330, I'm guessing we'll need to open discussions with nixf-diagnose regarding:

1. Implementing auto-fix for some specific lints.
2. Separating the "redundant parentheses" rule into subcategories, that we can selectively ignore.
3. Adding an "enforce clarifying parentheses" rule for specific scenarios
   (i.e. when using or in a list or function argument).

IDK whether these should be general "toggle the rule in x scenario" subcategories, or if it is fine to just have a "except when it comes to or" option. OTTOMH, that is the only scenario where clarifying parentheses are universally uncontroversial.

@inclyc would love to hear your opinion here.

And no, the upstream linter only has a single rule about that to warn about these - I think we should essentially disable this, when nixfmt can do it.

Would be easy to add more "rules" in nixf according to your feedback.

1. Implementing auto-fix for some specific lints.

It is currently supported in nixf library, but not landed in nixf-diagnose the wrapper.

See inclyc/nixf-diagnose#9

And no, the upstream linter only has a single rule about that to warn about these - I think we should essentially disable this, when nixfmt can do it.

Would be easy to add more "rules" in nixf according to your feedback.

That's great to hear. I'd probably start with:

• One rule to remove all redundant parentheses, except around ... or ... constructs.
• One rule to add parentheses around ... or ... constructs (essentially f x.a or b should be formatted to f (x.a or b) nixfmt#251)

And then when we do this across all of Nixpkgs, we might find more cases where parentheses should be kept.

I agree, unused let bindings should be cleaned up.

I think there is actually quite a lot of redundant code that would be removed here. I think this would hit entire definitions of things, so that's a big potential to remove dead stuff that actually simplifies maintenance.