-
Notifications
You must be signed in to change notification settings - Fork 7
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
one-line define behavior #51
Comments
That's kinda funny... Your proposed behavior is what I initially implemented. Then, I got suggestions from @Metaxal and @jackfirth to unconditionally enter newline, and I made the switch in 831bb4c#diff-28c7782bc7f8926245fb8e9a590152f17a45b0c9e3dd37d043811d02b8b88476. I want to note that it is possible for |
I do think the current setting is good. While in principle the two cases are semantically equivalent, I see the first case as a binding between a value and a variable, which should most of the time be a on-liner, while the second case is a function definition, which for consistency should have the body below it. I think this is a good default, but if this can be made user-adaptive that's even more awesome. That said, in case no local consensus can be reached, we could still put this to a vote on Discourse (asking for arguments, not just "feelings"), or I would also 100% trust @sorawee to make a reasonable and informed choice. There could also be a rule about whether to add a newline for the first case, based for example on the number of parentheses in the expression --- say, more than 2 pairs and that's a newline. |
I am not a fan of the following formatting:
I would personally like to define functions this small on one line, but I also want to use the shorthand version of
define
. I understand whether or not it should be one line is a matter of taste, but it doesn't make sense to me that the expression that is more noisy is the one that is formatted as one line. To me that feels like a less subjective inconsistency.The text was updated successfully, but these errors were encountered: