Crystal: Formatter add newlines after comments following a `when then` including a semicolon

[j8r]

The formatter adds one line and then another one line after comments following a when then that includes a semicolon.

case 0
when 0 then 1; 2
# Comments
end

will format firstly to

case 0
when 0 then 1; 2
# Comments

end

and then reformat again to

case 0
when 0 then 1; 2
# Comments


end

[RX14]

Should that even compile?

case x
when 0 then 1
  2
end

doesn't make sense to me.

[j8r]

It doesn't have less sense than #6367 . I have put here integers to reduce the problem, but it can be anything else. I use a big case with quite a lot of whens, that have small operations to do for each.

case var
# This do things
when "a" then dosome; puts "done"
# This do other
when "test" then other; puts "also done"
# to continue...
end

[Sija]

It doesn't have less sense than #6367

It does IMO have much less sense than having an empty case which in itself is... just that, empty. Not incomprehensible like the code posted above.

[j8r]

I don't get @Sija, what's incomprehensible? Each when do 2 operations.

[j8r]

The actual code is https://github.com/DFabric/dppm/blob/master/src/dppm/cmd.cr . Its clearer on a single line, because they are similar, and also most in term of size (so we can see "columns")

[straight-shoota]

It doesn't matter if there is a real use case and if that is better than it's alternatives.

A semicolon should always be usable to delimit an expression, as an alternative for a line break. This should just work an the same line as when ... then. It would be inconsistent and very awkward if this was a syntax error.

This just needs a fix in the formatter.

[RX14]

No, this should be a compile error because the code above is unreadable and anyone who wants to put two separate expressions inside a when should be using the standard case syntax, not the inline then syntax.

The compiler exists to detect bad or ambiguous (to the compiler or the human) code and reject it, and I can't think of any reason why this code couldn't always be replaced with

case x
when 0
  1
  2
end

Hence, I think it should be a compile error.

6367 was merged because it helped when macros were generating case blocks. This is unrelated. The very precedent that meant that an empty case was rejected in the first place implies that this syntax should be rejected.

If people really want to use this syntax, they can use

case 0
when 0 then (1; 2)
# Comments
end

which works and formats right now. The extra brackets help in showing that something weird is coming up.

[asterite]

What about begin? Do you forbid it? I think restricting this is unnecessary complexity in the compiler.