Conversation
piegamesde
left a comment
piegamesde
left a comment
There was a problem hiding this comment.
My intuition also says that putting the backpipes to the right might be beneficial, but until I've written any actual code to get a feeling for it I currently don't care. And this is undoubtedly the simpler implementation
src/Nixfmt/Types.hs
Outdated
| | TNot | ||
| | TUnequal | ||
| | TPipeTo | ||
| | TPipeFrom |
There was a problem hiding this comment.
Small nit: I'd prefer PipeRight and PipeLeft (or PipeForward/PipeBackwards) as names, as they're a bit more visual.
| ( | ||
| g { } | ||
| <| f "very long argument should justify splitting this over multiple lines" | ||
| <| a // b | ||
| ) |
There was a problem hiding this comment.
What I like about the |> formatting is that the functions, that have an equal role, are formatted equally.
This makes it easy to read.
That is not the case here. This formatting makes it seem as if g { } is special and f "..." and a // b are similar, while the opposite is true.
| ( | |
| g { } | |
| <| f "very long argument should justify splitting this over multiple lines" | |
| <| a // b | |
| ) | |
| ( | |
| g { } <| | |
| f "very long argument should justify splitting this over multiple lines" <| | |
| a // b | |
| ) |
A similar effect could be achieved by indenting the first function, but that's a little unusual, and it doesn't make the function operands look quite as equal.
| ( | |
| g { } | |
| <| f "very long argument should justify splitting this over multiple lines" | |
| <| a // b | |
| ) | |
| ( | |
| g { } | |
| <| f "very long argument should justify splitting this over multiple lines" | |
| <| a // b | |
| ) |
There was a problem hiding this comment.
The first suggested style has the problem that lines might be arbitrarily long, which makes it unclear how the lines relate to, without looking to the right. This is why the standard always puts operators in front.
The second suggested style violates the indentation rule of the standard.
But we also agree that it's not ideal for the first function to look different. For now we don't want to block on this and just go ahead with this PR as is.
It would also be possible for NixOS/rfcs#148 to specify how it should be formatted (though it doesn't actually specify a <| operator right now).
infinisil
left a comment
infinisil
left a comment
There was a problem hiding this comment.
(reviewed during the formatting team meeting)
| ( | ||
| g { } | ||
| <| f "very long argument should justify splitting this over multiple lines" | ||
| <| a // b | ||
| ) |
There was a problem hiding this comment.
The first suggested style has the problem that lines might be arbitrarily long, which makes it unclear how the lines relate to, without looking to the right. This is why the standard always puts operators in front.
The second suggested style violates the indentation rule of the standard.
But we also agree that it's not ideal for the first function to look different. For now we don't want to block on this and just go ahead with this PR as is.
It would also be possible for NixOS/rfcs#148 to specify how it should be formatted (though it doesn't actually specify a <| operator right now).
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/formatting-team-meeting-2024-08-06/50222/1 |
6 participants
NixOS/nix#11131 landed 🎉
Let the debates about the proper formatting of these particular operators begin! Should they use the same rules as all other operators? This PR assumes yes, but there's an argument for sticking
<|at the ends of lines rather than at the beginnings, since it is the final value in a chain of<|s that is special. 🤷