Fix a typo in the specification of switch cases.

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification \\
 {\large Version 1.10}}
@@ skipping 5723 matching lines @@
 \LMHash{}
 The {\em switch statement} supports dispatching control among a large number of cases.
 
  \begin{grammar}
 {\bf switchStatement:}
       \SWITCH{} `(' expression `)' `\{' switchCase* defaultCase? `\}'% could do top level here and in cases
     .
 
 
 {\bf switchCase:}
-      label* (\CASE{} expression `{\escapegrammar :}') statements
+      label* \CASE{} expression `{\escapegrammar :}' statements
     .
 
 {\bf defaultCase:}
       label*  \DEFAULT{} `{\escapegrammar :}' statements
     .
  \end{grammar}
  
 \LMHash{}
  Given a switch statement of the form 
  
 \begin{dartCode}
-\SWITCH{} ($e$) \{ 
-   \CASE{} $label_{11} \ldots label_{1j_1}$ $e_1: s_1$ 
-   $\ldots$  
-   \CASE{} $label_{n1} \ldots label_{nj_n}$ $e_n: s_n$ 
-   \DEFAULT{}: $s_{n+1}$ 
+\SWITCH{} ($e$) \{
+   $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
+   $\ldots$
+   $label_{n1} \ldots label_{nj_n}$ \CASE{} $e_n: s_n$
+   $label_{(n+1)1} \ldots label_{(n+1)j_{n+1}}$ \DEFAULT{}: $s_{n+1}$
 \}
 \end{dartCode}
  
  or the form 
  
 \begin{dartCode}
-\SWITCH{} ($e$) \{ 
-   \CASE{} $label_{11} \ldots label_{1j_1}$ $e_1: s_1$
-   $\ldots$  
-   \CASE{} $label_{n1} \ldots label_{nj_n}$ $e_n: s_n$ 
+\SWITCH{} ($e$) \{
+   $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
+   $\ldots$
+   $label_{n1} \ldots label_{nj_n}$ \CASE{} $e_n: s_n$
 \}
 \end{dartCode}
  
  it is a compile-time error if the expressions $e_k$ are not compile-time constants for all  $k \in 1..n$.  It is a compile-time error if the values of the expressions $e_k$ are not either:
  \begin{itemize}
  \item instances of the same class $C$, for all $k \in 1..n$,  or 
  \item instances of a class that implements \cd{int}, for all $k \in 1..n$,  or 
  \item instances of a class that implements \cd{String}, for all $k \in 1..n$. 
  \end{itemize}
  
 \commentary{In other words,  all the expressions in the cases evaluate to constants of the exact same user defined class or are of certain known types.  Note that the values of the expressions are known at compile-time, and are independent of any static type annotations.
 }
 
 \LMHash{}
 It is a compile-time error if the class $C$ has an implementation of the operator $==$ other than the one inherited from \code{Object} unless the value of the expression is a string, an integer, literal symbol or the result of invoking a constant constructor of class \cd{Symbol}.
  
  \rationale{
  The prohibition on user defined equality allows us to implement the switch efficiently for user defined types. We could formulate matching in terms of identity instead with the same efficiency. However, if a type defines an equality operator, programmers would find it quite surprising that equal objects did not match.
  
  }
 
 \commentary{
 The \SWITCH{}  statement should only be used in very limited situations (e.g., interpreters or scanners).  
 }
 
 \LMHash{}
 Execution of a switch statement of the form
 
 \begin{dartCode}
-\SWITCH{} ($e$) \{ 
-   \CASE{} $label_{11} \ldots label_{1j_1}$ $e_1: s_1$ 
-   $\ldots$  
-   \CASE{} $label_{n1} \ldots label_{nj_n}$ $e_n: s_n$ 
-   \DEFAULT{}: $s_{n+1}$ 
+\SWITCH{} ($e$) \{
+   $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
+   $\ldots$
+   $label_{n1} \ldots label_{nj_n}$ \CASE{} $e_n: s_n$
+   $label_{(n+1)1} \ldots label_{(n+1)j_{n+1}}$ \DEFAULT{}: $s_{n+1}$
 \}
 \end{dartCode}
  
 or the form 
  
 \begin{dartCode}
-\SWITCH{} ($e$) \{ 
-   \CASE{} $label_{11} \ldots label_{1j_1}$ $e_1: s_1$
-   $\ldots$  
-   \CASE{} $label_{n1} \ldots label_{nj_n}$ $e_n: s_n$ 
+\SWITCH{} ($e$) \{
+   $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
+   $\ldots$
+   $label_{n1} \ldots label_{nj_n}$ \CASE{} $e_n: s_n$
 \}
 \end{dartCode}
 
 proceeds as follows:
 
 \LMHash{}
 The statement \code{\VAR{} id = $e$;} is evaluated, where \code{id} is a variable whose name is distinct from any other variable in the program. In checked mode, it is a run time error if the value of $e$ is not an instance of the same class as the constants $e_1 \ldots e_n$. 
 
 \commentary{Note that if there are no case clauses ($n = 0$), the type of $e$ does not matter.}
 
 \LMHash{}
 Next, the case clause \CASE{} $e_{1}: s_{1}$ is executed if it exists. If \CASE{} $e_{1}: s_{1}$ does not exist, then if there is a  \DEFAULT{} clause it is executed by executing $s_{n+1}$.
 
 \LMHash{}
 A case clause introduces a new scope, nested in the lexically surrounding scope. The scope of a case clause ends immediately after the case clause's statement list.
 
 \LMHash{}
 Execution of a \CASE{} clause \CASE{} $e_{k}: s_{k}$ of a  switch statement  
 
 \begin{dartCode}
-\SWITCH{} ($e$) \{ 
-   \CASE{} $label_{11} \ldots label_{1j_1}$ $e_1: s_1$ 
-   $\ldots$  
-   \CASE{} $label_{n1} \ldots label_{nj_n}$ $e_n: s_n$ 
-   \DEFAULT{}: $s_{n+1}$ 
+\SWITCH{} ($e$) \{
+   $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
+   $\ldots$
+   $label_{n1} \ldots label_{nj_n}$ \CASE{} $e_n: s_n$
+   $label_{(n+1)1} \ldots label_{(n+1)j_{n+1}}$ \DEFAULT{}: $s_{n+1}$
 \}
 \end{dartCode}
 
 proceeds as follows:
 
 \LMHash{}
 The expression \code{$e_k$ == id} is evaluated to an object $o$ which is then subjected to boolean conversion yielding a value $v$. 
 If $v$ is not  \TRUE{} the following case,  \CASE{} $e_{k+1}: s_{k+1}$ is executed if it exists. If  \CASE{} $e_{k+1}: s_{k+1}$ does not exist, then the \DEFAULT{} clause is executed by executing $s_{n+1}$.
 If $v$ is \TRUE{},   let $h$ be the smallest number such that $h \ge k$ and $s_h$ is non-empty. If no such $h$ exists, let $h = n + 1$. The  sequence of statements $s_h$ is then executed.
 If execution reaches the point after $s_h$  then  a runtime error occurs, unless $h = n+1$.
 
 \LMHash{}
 Execution of a \CASE{} clause \CASE{} $e_{k}: s_{k}$ of a  switch statement  
 
 \begin{dartCode}
-\SWITCH{} ($e$) \{ 
-   \CASE{} $label_{11} \ldots label_{1j_1}$ $e_1: s_1$
-   $\ldots$  
-   \CASE{} $label_{n1} \ldots label_{nj_n}$ $e_n: s_n$ 
+\SWITCH{} ($e$) \{
+   $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
+   $\ldots$
+   $label_{n1} \ldots label_{nj_n}$ \CASE{} $e_n: s_n$
 \}
 \end{dartCode}
 
 proceeds as follows:
 
 \LMHash{}
 The expression \code{$e_k$ == id} is evaluated to an object $o$ which is then subjected to boolean conversion yielding a value $v$. 
 If $v$ is not  \TRUE{} the following case,  \CASE{} $e_{k+1}: s_{k+1}$ is executed if it exists. 
 If $v$ is \TRUE{},   let $h$ be the smallest integer such that $h \ge k$ and $s_h$ is non-empty. The  sequence of statements $s_h$ is  executed if it exists.
 If execution reaches the point after $s_h$  then  a runtime error occurs, unless $h = n$.
 
 
 \commentary{
-In other words, there is no implicit fall-through between cases. The last case in a switch (default or otherwise) can `fall-through' to the end of the statement.
+In other words, there is no implicit fall-through between non-empty cases. The last case in a switch (default or otherwise) can `fall-through' to the end of the statement.
 }
 
 \LMHash{}
 It is a static warning if the type of $e$ may not be assigned to the type of $e_k$. It is a static warning if the last statement of the statement sequence $s_k$ is not a \BREAK{}, \CONTINUE{}, \RETURN{} or \THROW{} statement.
 
 \rationale{
 The behavior of switch cases intentionally differs from the C tradition.  Implicit fall through is a known cause of programming errors and therefore disallowed.  Why not simply break the flow implicitly at the end of every case, rather than requiring explicit code to do so?  This would indeed be cleaner.  It would also be cleaner to insist that each case have a single (possibly compound) statement.  We have chosen not to do so in order to facilitate porting of switch statements from other languages.  Implicitly breaking the control flow at the end of a case would silently alter the meaning of ported code that relied on fall-through, potentially forcing the programmer to deal with subtle bugs. Our design ensures that the difference is immediately brought to the coder's attention.  The programmer will be notified at compile-time if they forget to end a case with a statement that terminates the straight-line control flow. We could make this warning a compile-time error, but refrain from doing so because do not wish to force the programmer to deal with this issue immediately while porting code.  If developers ignore the warning and run their code, a run time error will prevent the program from misbehaving in hard-to-debug ways (at least with respect to this issue).
 
 The sophistication of the analysis of fall-through is another issue. For now, we have opted for a very straightforward syntactic requirement. There are obviously situations where code does not fall through, and yet does not conform to these simple rules, e.g.:
 }
@@ skipping 1921 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------