Rewrite `[ foo ] ++ bar` to `foo :: bar`?

[rtfeldman]

elm-analyse gives a warning for this situation:

If you concatenate two lists, but the [left hand side is a single element list literal], then you should use the cons operator.

This seems like not only a stylistic concern, but a performance optimization!

I can't think of any situations where it would be better to write e.g. [ foo ] ++ anyOtherList than foo :: anyOtherList. Should elm-format automatically perform this rewrite?

[basile-henry]

What about the following line:

oneList ++ [ oneItem ] ++ anotherList

From a purely stylistic point of view I think it looks nicer than:

oneList ++ (oneItem :: anotherList)

I assumed the elm compiler would optimise the second append, but I guess if it doesn't, maybe style doesn't matter as much.

Now even if we do want the optimised version, is it really the role of elm-format to apply this change?

[ahstro]

@basile-henry Actually, since (++) and (::) are both right associative and have the same precedence (source), the parentheses are superfluous and, if that feature sticks, will be automatically removed by elm-format, so the end code would be

oneList ++ oneItem :: anotherItem

I'm not sure whether that is stylistically better or worse than the first alternative. I do share your concern whether this is elm-format's area of responsibility though.

[drathier]

I'd vote against this. Symmetry in code is useful for readability, so having both [a] ++ b and b ++ [a] is more readable, symmetry-wise, than replacing it with ::. This optimisation should be trivial to add to the compiler if anyone wants to take a stab at it.

[jfmengels]

Not to dig up a very old issue, but elm-review-simplify now does this transformation.

elm-review then applies elm-format so it removes the extra parens is they prove to not be needed.

I don't know if I would have liked elm-format to do this change, but at least it's available somewhere, and people can choose not to opt-in if they don't like it.