don't give up @layus ! the format is definitely up for discussion

from nixpkgs-fmt.

This is sort of intentional, see #46.

The problem with placing first parameter after { is that it forces parameters to align to {, which doesn't work to well in cases like this:

{
  f = { x
      , y 
      }: body
}

from nixpkgs-fmt.

Fair point indeed.

That being said, top-level functions are a bit different and could be handled differently, because this example looks like an unfinished tetris game. The curly bracket is itching to fall one square below ;-).

But this has already been discussed, so closing for now.

{ 
  foo
, bar
, baz
}:
foo + bar

Okay examples

{
  foo,
  bar,
  baz
}:
foo + bar

{ foo
, bar
, baz
}:
foo + bar

{
  f = { x
      , y
      , z
      }: body;
}

{
  f = { 
    x,
    y,
    z,
  }: body;
}

Not okay examples

{ 
  foo
, bar
, baz
}:
foo + bar

{
  f = { 
    x
  , y
  , z
  }: body;
}

from nixpkgs-fmt.

This is the hardest problem we've had with the nix format, making it work in the top-level and deeper levels. We haven't found a solution that keep the rules simple.

I guess an alternative would be to force the deeper level to be on multiple lines like that:

{
  f =
    { x
    , y
    , z
    }: body;
}

from nixpkgs-fmt.

I guess an alternative would be to force the deeper level to be on multiple lines like that:

{
  f =
    { x
    , y
    , z
    }: body;
}

That's definitely an option, and it looks quite nice to me. Especially given that nested functions that receive an attrset as argument do not look too frequent in nixpkgs.

from nixpkgs-fmt.

Function parameters are hard, because they have no opening and closing symbols. We could use λ a: b: c: 1 for the sake of reasoning. then an argument list is just like a normal list. See the simmilarity between these two ?

{
  f = λ
    { x, y, z}:
    foo:
    { a, b, c}:
    bar:
	  body;
}

{
  f = [
    { x, y, z}
    foo
    { a, b, c}
    bar
  ];
}

So either the arguments are on the same line, or they are on separate lines, with a leading newline. That rule is easy to state, and somewhat alleviates our current issue.

Fully expanded ;-):

{
  f =
    { x
    , y
    , z
    }:
    foo:
    { a
    , b
    , c
    }:
    bar:
      body;
}

[Edit] replace tabs with spaces

from nixpkgs-fmt.

Why are foo: and bar: indented once more in your example? The array argument should dictate that all the function arguments would be aligned on the same indent?

from nixpkgs-fmt.

they say a figure is better than a thousand words ;-), so here it comes:

{
  f =
    set1:
    foo:
    set2:
    bar:
	  body;
}

{
  f =
    {
      x,
      y,
      z
    }:
    foo:
    { 
      a,
      b,
      c
    }:
    bar:
	  body;
}

from nixpkgs-fmt.

Why are foo: and bar: indented once more in your example? The array argument should dictate that all the function arguments would be aligned on the same indent?

They are not. Could it be a tab vs spaces issue ? I edited my previous comment to fix that.

from nixpkgs-fmt.

Okay that makes more sense now with the indent fixed :)

I think the body will have to be on the same level as the argument to avoid too much movement:

single-line:

{
  f = a: b: c:
    body;
}

multi-line:

{
  f =
    a:
    b:
    c:
    body;
}

If the body is really large it will create a lot of whitespace diff otherwise.

from nixpkgs-fmt.

And if that's applied then we can keep the comma-first notation for the function arguments. This notation is quite pervasive in nixpkgs:

{ foo
, bar
, baz
}:

from nixpkgs-fmt.

What we do in canonix is to format top-level differently than inline.

from nixpkgs-fmt.