avh4 / elm-format

elm-format formats Elm source code according to a standard set of rules based on the official Elm Style Guide
BSD 3-Clause "New" or "Revised" License
1.31k stars 148 forks source link

Remove parens surrounding function return type in type annotation #719

Open jfmengels opened 3 years ago

jfmengels commented 3 years ago

I sometimes see functions with the following type annotation:

fun : a -> b -> (c -> d)

which is equivalent to

fun : a -> b -> c -> d

I think the first version feels more complex than the latter, because the parens make me think that what I'm looking at is an argument function of type c -> d. Then my brain gets confused because there is nothing after what I thought was an argument.

I thought about writing an elm-review rule for this, but I feel like this would be better handled by elm-format.

I could imagine some people liking writing something like this

fun : ExplicitlyUsed -> (Implicit -> Return)
fun explicit =
  curriedFunction explicit

but I don't think that brings value in practice, but YMMV.

avh4 commented 3 years ago

This was something I did make an intentional choice about when implementing, thinking that especially for "lift" style functions like (a -> b) -> (Maybe a -> Maybe b), leaving the parens might be desirable for the documentation.

But now that it's been around a long time, I think that comes up so infrequently that that use case probably doesn't matter.

jfmengels commented 3 years ago

One reason why it comes up so infrequently could be because the packages website removes the parens in the documentation. So even if you annotate a function like (a -> b) -> (Maybe a -> Maybe b), it will show up as (a -> b) -> Maybe a -> Maybe b.

Making this change would make the types consistent with that at least :man_shrugging: