Absorb single-line destructured params into parenthesized functions

[dyegoaurelio]

closes #375

[github-actions]

Nixpkgs diff

[dyegoaurelio]

I didn't expect that the nixpkgs diff would be that big

[MattSturgeon]

Thanks for taking the time to implement this!

I still think it's generally the right direction. However, I'm also a little cautious of the implications for diff noise resulting from indentation changing back and forth, which I hadn't considered in the last meeting.

[MattSturgeon]

Is it also worth considering whether the set pattern has an @-name?

E.g. { foo, bar, ... } is fairly trivial, but { foo, bar, ... }@args is less so.

And/or consider the total char count of the formatted set pattern (including @-name and braces), similar to how we count the total chars of a formatted line? That'd account for long arg names and long @-names.

[MattSturgeon]

Is there a way to "soft absorb", allowing us to respect line breaks in user input?

E.g. if the user explicitly wants

{ foo, ... }:
{ }

to have the function body on a separate line, we could respect this.

[MattSturgeon]

I think this may be useful for modules, where it is common to add/remove attrs from the destructured set pattern.

Frequently switching between 2-3 attrs would cause frequent indentation change diffs.

Especially for modules defined within a wider expression, e.g.:

{
  perSystem =
    { pkgs, system, ... }:
    { };
}

If we start adding/removing a third argument from that example, the entire function body gets indented/dedented.

[MattSturgeon]

This would also avoid a treewide nixpkgs diff, since we already have the line breaks in nixpkgs.

Instead, we'd have the option of looking for functions that benefit from absorbed formatting and manually removing their line breaks.

[dyegoaurelio]

this would be tricky to implement. We don't have the concept of soft absorption in the formatter.

Another alternative would be to don't mark the expression as absorbable if the source line is the same as it's parent.

However, given this input

    perSystem =
      { pkgs, system, ... }:
      {
        out = pkgs.lib.optionalString (system == "x86_64-linux") "foo";
      };
    
    perSystem = { pkgs, system, ... }:
      {
        out = pkgs.lib.optionalString (system == "x86_64-linux") "foo";
      };

the goal would be to not absorb the first one, but absorb the second one, right?

The problem is that for both cases we'd be resolving whether the expression

{ pkgs, system, ... }:
      {
        out = pkgs.lib.optionalString (system == "x86_64-linux") "foo";
      };

is absorbable. (it has no context about where it's positioned)

[dyegoaurelio]

So in short, it's possible but would require much more changes to the code

[piegamesde]

Is this really an improvement? IMO, mixed plain and attrs function args should not be on the same line

[piegamesde]

Closing parenthesis is wrong here

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/formatting-team-meeting-2026-03-31/76739/1