-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support pipe operators #227
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -424,6 +424,8 @@ data Token | |||
| TLessEqual | |||
| TNot | |||
| TUnequal | |||
| TPipeTo | |||
| TPipeFrom |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small nit: I'd prefer PipeRight and PipeLeft (or PipeForward/PipeBackwards) as names, as they're a bit more visual.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
( | ||
g { } | ||
<| f "very long argument should justify splitting this over multiple lines" | ||
<| a // b | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
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. 🤷