What's the problem with Allman style and an `except` keyword?

[bergus]

I was re-reading Why else? and came across the section

The only fix for this (that we've seen so far) is to disallow semicolon insertion after except (...) clauses. But this is fairly distasteful; it would disallow "Allman style"

try
{
  f();
}
except (e match SyntaxError)
{
  b();
}
except (e)
{
  c();
}

which is popular with at least some programmers. This degree of whitespace sensitivity is not generally desirable in the language.

I do understand the ambiguity, but I don't understand why ASI would need to be adapted to fix the ambiguity or how this fix would prevent programmers from using Allman style. As far as I know, ASI only happens when the program would be syntactically invalid without the semicolon at the end of the line. When multiple except clauses follow a try block, it's a valid program and ASI wouldn't even take place.

The only "problem" I can see is when someone uses multiple except(…)s but expects one of them to be a function call followed by a block - to do so, he has to use except(…); with a semicolon and cannot rely on ASI (like in some other places). But such code does not exist in any serious code base, so I tend to ignore that inconvenience.

[dead-claudia]

Which is that equivalent to?

// 1.
try {
  f();
} except (e match SyntaxError) {
  b();
} except (e) {
  c();
}

// 2.
try {
  f();
} except (e match SyntaxError) {
  b();
}

except(e);
{
  c();
}

[inikulin]

@isiahmeadows The second one.

[bergus]

@isiahmeadows That would depend on the grammar. If multiple except clauses are allowed by the grammar, it would be equivalent to the first one, as ASI would have no need to insert a semicolon after the except(e). @inikulin how is that?

[inikulin]

@bergus

@inikulin how is that?

With current ASI behavior it will be transformed to 2.

[bergus]

@inikulin Which of the rules are you applying here? We assume that 1) would be valid production, don't we? The { after the expect(e) is neither an offending, EOF or restricted token, so there is no semicolon inserted.

[inikulin]

@bergus

a token (called the offending token) is encountered that is not allowed by any production of the grammar,

expect(e){} is not allowed. { is an offending token.

then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true: The offending token is separated from the previous token by at least one LineTerminator.

We have a line terminator here between expect(e) and {

[bergus]

@inikulin Ah, sure, I had expected it would be allowed if such a pattern-matching proposal with multiple (except or otherwise) cases was designed, since that seemed to be the whole point of the example. The 1. example should definitely be allowed (without ASI).

So, no problems with the rules for ASI, and no problems with using except as a contextual keyword. @domenic can you please fix the document?