Stream: ideas

Topic: formatting spaces around collection literals

Richard Feldman (Mar 29 2022 at 04:28):

so in Elm, elm-format formats lists like this:

[ a, b, c ]

I wrote the original design doc for elm-format, and my reasoning for this design was to be consistent with the vertical style, which was this:

[ a
, b
, c
]

so the idea was that there would consistently be a space between the opening brace and the first element, regardless of whether it was written vertically or horizontally

Richard Feldman (Mar 29 2022 at 04:29):

in Roc, our vertical format looks like this:

list = [
    a,
    b,
    c,
]

Richard Feldman (Mar 29 2022 at 04:30):

so we could do the horizontal style either way:

[ a, b, c ]

[a, b, c]

Richard Feldman (Mar 29 2022 at 04:31):

in a couple of weeks I'm gonna give a fairly extended demo of examples/gui, so I figured I'd bring this up now before then in case it makes sense to change

Richard Feldman (Mar 29 2022 at 04:31):

one of the implications of this would be that it would impact type annotations as well, so for example the type of List.get would change:

get : List elem, Nat -> Result elem [ OutOfBounds ]*

get : List elem, Nat -> Result elem [OutOfBounds]*

Richard Feldman (Mar 29 2022 at 04:32):

I don't have a strong preference either way on [ a, b, c ] vs [a, b, c] but I do like the error type being more compact in get

of note, I think it's important to be consistent on these - so if lists are compact, records should be too - e.g. {x, y, z} over { x, y, z } - as should imports and such in module headers

Richard Feldman (Mar 29 2022 at 04:32):

curious what others think!

Brendan Hansknecht (Mar 29 2022 at 04:33):

I am partial to adding the space. Just find that I have been adding it to my code (tags and lists) cause it makes things slightly more readable to me, but no major opinion.

Brendan Hansknecht (Mar 29 2022 at 04:34):

I find I want it most with tags that have type variables: [Err a] just reads weird to me without the spaces

Brendan Hansknecht (Mar 29 2022 at 04:34):

Or worse: [T a b] or [T (Dict k v) b]

Richard Feldman (Mar 29 2022 at 04:37):

is that only if it's a single tag?

e.g. how do you feel about these?

Bool : [ True, False ]
Result ok err : [ Ok ok, Err err ]

Bool : [True, False]
Result ok err : [Ok ok, Err err]

Brendan Hansknecht (Mar 29 2022 at 04:56):

I still likely it slightly better with the space. I guess it also depends a lot of the syntax coloring though.

Brendan Hansknecht (Mar 29 2022 at 04:56):

By making the brackets hide more with coloring, space or not matters even less.

Brendan Hansknecht (Mar 29 2022 at 04:57):

Maybe this means the brackets in my color scheme are too bold so I want the space.

Jared Cone (Mar 29 2022 at 05:02):

would this affect parenthesis as well? someFunc (someOtherFunc "hello") vs someFunc ( someOtherFunc "hello" ). If not then maybe that could be an argument for no spaces for [] or {} as well

Anton (Mar 29 2022 at 07:18):

Not having a space would simplify things for the editor because I wouldn't need to add or remove spaces for multi-line vs single-line vs empty lists/records. Although in design in general, having more spacing between elements is nicer to look at.

Kevin Gillette (Mar 29 2022 at 14:12):

I'm confident people will get used to it either way, just as you see people get used to reading code when you take away token-based syntax highlighting in favor of a more useful contextual colorization.

Kevin Gillette (Mar 29 2022 at 14:15):

If we add more spacing we should also (I believe) encourage formatting styles that keep elements together: perhaps give your error union a name instead of wrapping it over multiple lines, or have a consistent roc-format convention for a multi line annotation when it doesn't fit within however many characters on a single line

Richard Feldman (Mar 29 2022 at 14:29):

Jared Cone said:

would this affect parenthesis as well? someFunc (someOtherFunc "hello") vs someFunc ( someOtherFunc "hello" ). If not then maybe that could be an argument for no spaces for [] or {} as well

personally I don't think parens should have spaces regardless. (They don't currently.)

Jared Cone (Mar 29 2022 at 15:12):

Agreed. Then that could be a minor argument for not using spaces for the other brackets. I'm in the same boat as everyone else where I don't really care, just trying to think of some logic for one way or the other :)

Richard Feldman (Mar 29 2022 at 17:26):

seems like this is a minor enough consideration either way that it's not worth changing anything; I'll plan to do the demo with the current formatting! :thumbs_up:

Last updated: Jun 16 2026 at 16:19 UTC