Skip to content
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

Separate the field access function from an operator automatically #677

Open
jfmengels opened this issue May 16, 2020 · 0 comments
Open

Separate the field access function from an operator automatically #677

jfmengels opened this issue May 16, 2020 · 0 comments
Labels
0.9 (temporary label for search filtering) feature for developers full operators list Features that require knowledge of the complete list of defined operators
Milestone

Comments

@jfmengels
Copy link

Quite often, I write code similar to the following:

result = someRecord|>.field

which then gets reformatted to

result =
    someRecord |>. field

which does not compile, because |>. is not a known operator.
This is "syntactically" the correct change, as even in the first case, the code does not compile for the same reason.

Since elm-format likes to fix syntax errors to help the user out without them noticing, I thought maybe it could also help them by reformatting to the following instead:

result =
    someRecord |> .field

I think the same thing would be worthwhile for <|, <<, >>, and potentially all operators.

This is my proposal:
When seeing code of the form <known operator>.<valid field name>, reformat it to <known operator> .<valid field name>.

AFAIK, there is only |. from Parser and Parser.Advanced which ends with a ., but since | is not a known operator, this wouldn't be ambiguous.

Since the number of operators is limited and has been stable for quite a while now, I think it would be reasonably safe to fix it the proposed way but you may righteously disagree, and that would be a good reason to decide against this proposal 👍

Thanks for all your work on elm-format! ❤️

@avh4 avh4 added the full operators list Features that require knowledge of the complete list of defined operators label Mar 17, 2023
@avh4 avh4 added the 0.9 (temporary label for search filtering) label Mar 17, 2023
@avh4 avh4 added this to the 0.9.1-exp milestone Apr 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.9 (temporary label for search filtering) feature for developers full operators list Features that require knowledge of the complete list of defined operators
Projects
None yet
Development

No branches or pull requests

2 participants