-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
Allow elmish style tuples #10186
Allow elmish style tuples #10186
Conversation
Since Fsharplint is using this styleguide as source and ionide is using fsharplint, it seems this guide is going to be the canonical styleguide. In general I think this is a good thing and I try to be not too opionated here (which is hard). Anyway, I'd like to suggest a small change to the very restrictive tuple instantiation. The new fsharplint is complaining on thousands of lines in our elmish update functions. Stuff that we as community suggested to use for everyone in safe stack. Basically all samples and all existing safe stack code is now considered as bad. I'm not sure if my wording here is good, but I want to open up the discussion.
A few times, I've been facing ambiguous issues around tuple instanciation and pattern matching, and those issues have been solved using explicit parens (dotnet/fsharp#5259 is example of me tripping on this), like it is the case in several areas of F#.
I feel code is more readable when parens are only added when necessary or when it clarifies possible ambiguity (despite not being necessary in all cases, the guideline to wrap would apply when some of the elements are not mere identifers or literals, but more complex expressions). I'd like to relax the guidelines along those lines. Ideally, in the tradition of Resharper in C#, I'd like the tooling to propose me to wrap / unwrap expressions which has extraneous parens or lacking parens, and have some place to define my prefered styling. |
I think the addition requested by @forki make sense when we consider Elmish applications. |
There is another argument for lifting the restriction: symmetry. If we don't require it in destructering/pattern matching, then we should not do it in construction. |
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.
Some quick changes, but I otherwise think that this is good.
Can you also update line 258 along the following lines?
"A tuple instantiation should generally have the right-hand side parenthesized, and the [...]"
Co-Authored-By: forki <[email protected]>
Co-Authored-By: forki <[email protected]>
Co-Authored-By: forki <[email protected]>
Applied your suggestions. Thx. (btw that new github feature is rad) |
@forki Yep, whoever built that out deserves a raise |
Here's what your change looks like: Merging, thanks @forki |
You can also batch them in one commit via the Files tab. I love that feature! |
Since Fsharplint is using this styleguide as source and ionide is using fsharplint, it seems this guide is going to be the canonical styleguide. In general I think this is a good thing and I try to be not too opionated here (which is hard).
Anyway, I'd like to suggest a small change to the very restrictive tuple instantiation. The new fsharplint is complaining on thousands of lines in our elmish update functions. Stuff that we as community suggested to use for everyone in safe stack. Basically all samples and all existing safe stack code is now considered as bad.
I'm not sure if my wording here is good, but I want to open up the discussion.