[patterns] More small fixes. (#2675)

* [patterns] More small fixes.

- Specify exhaustiveness checking of switch elements.
- Resolve ambiguity with `=>` in switch expression guards.
- Compile error if map pattern has identical keys.

Fix #2672.
Fix #2657.

* Clarify when restriction on "=>" in guards comes into play.

Author: munificent

accepted/future-releases/0546-patterns/feature-specification.md

@@ -4,7 +4,7 @@ Author: Bob Nystrom
 
 Status: Accepted
 
-Version 2.18 (see [CHANGELOG](#CHANGELOG) at end)
+Version 2.19 (see [CHANGELOG](#CHANGELOG) at end)
 
 Note: This proposal is broken into a couple of separate documents. See also
 [records][] and [exhaustiveness][].
@@ -595,6 +595,15 @@ It is a compile-time error if:
 
 *   Any of the entry key expressions are not constant expressions.
 
+*   If any two keys in the map are identical. *Map patterns that don't have a
+    rest element only match if the `length` of the map is equal to the number of
+    map entries. If a map pattern has multiple identical key entries, they will
+    increase the required length for the pattern to match but in all but the
+    most perverse `Map` implementations will represent the same key. Thus, it's
+    very unlikely that any map pattern containing identical keys (and no rest
+    element) will ever match. Duplicate keys are most likely a typo in the
+    code.*
+
 *   If any two keys in the map both have primitive `==` methods, then it is a
     compile-time error if they are equal according to their `==` operator. *In
     cases where keys have types whose equality can be checked at compile time,
@@ -1231,6 +1240,67 @@ of an expression statement. This is similar to existing restrictions on map
 literals appearing in expression statements. In the rare case where a user
 really wants one there, they can parenthesize it.
 
+#### Function expression in guard ambiguity
+
+Function expressions also use `=>`, which leads to a potential ambiguity:
+
+```dart
+var x = switch (obj) {
+  _ when a + (b) => (c) => body
+};
+```
+
+This could be interpreted as either:
+
+```dart
+var x = switch (obj) {
+  _ when (a + (b)) => ((c) => body)
+  //     ---------    -------------
+};
+
+var x = switch (obj) {
+  _ when (a + (b) => (c)) => (body)
+  //     ----------------    ------
+};
+```
+
+A similar ambiguity exists with function expressions in initializer lists, if
+the constructor happens to be a factory constructor with `=>` for its body. We
+resolve the ambiguity similarly here:  When `=>` is encountered after `when` in
+a guard, if the code between forms a valid expression, then it is interpreted as
+such and the `=>` is treated as the separator between the guard and case body.
+*In the above example, we take the first interpretation.*
+
+This rules applies in all contexts where a guard can appear: switch statements,
+switch elements, switch expressions, and if-case statements. *We could restrict
+this rule to guards only in switch expressions where the ambiguity arises, but
+that leads to a syntactic restriction that is context-sensitive and harder to
+learn. Since the rule is unusual enough as it is, we apply it as consistently as
+possible. Note that the related restriction on `=>` in constructor initializers
+applies even though generative constructors can't use `=>` for their body.*
+
+The rule is applied unconditionally even if the code after `=>` is not a valid
+body expression, as in:
+
+```dart
+var x = switch (obj) {
+  _ when (a) => b => c
+};
+```
+
+Here, we treat the guard expression as `(a)`, which leads the body to be `b =>
+c` which isn't a valid expression and produces a compile-time error.
+
+If you want a guard expression that ends in a function expression (which is
+quite unlikely), you can avoid the `=>` being captured as the case separator by
+parenthesizing the function:
+
+```dart
+var x = switch (obj) {
+  _ when ((a) => b) => c
+};
+```
+
 ### If-case statement and element
 
 Often you want to conditionally match and destructure some data, but you only
@@ -2265,8 +2335,9 @@ All other types are not exhaustive. Then:
     is to throw an error and most Dart users prefer to catch those kinds of
     mistakes at compile time.*
 
-*   It is a compile-time error if the cases in a switch statement are not
-    exhaustive and the static type of the matched value is an exhaustive type.
+*   It is a compile-time error if the cases in a switch statement or switch
+    collection element are not exhaustive and the static type of the matched
+    value is an exhaustive type.
 
 [exhaustiveness]: https://github.com/dart-lang/language/blob/master/accepted/future-releases/0546-patterns/exhaustiveness.md
 
@@ -3122,6 +3193,14 @@ Here is one way it could be broken down into separate pieces:
 
 ## Changelog
 
+### 2.19
+
+-   Specify exhaustiveness checking of switch elements.
+
+-   Resolve ambiguity with `=>` in switch expression guards (#2672).
+
+-   Compile error if map pattern has identical keys (#2657).
+
 ### 2.18
 
 -   Support negative number literals in patterns (#2663).