[swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

Xiaodi Wu xiaodi.wu at gmail.com
Mon Apr 3 01:10:26 CDT 2017


On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan <daniel at duan.org> wrote:

<snip>

> 4.
> The proposal does not explore what happens when the proposed prohibition
> on "mixing and matching" the proposed sugared and unsugared pattern
> matching runs up against associated values that have a mix of labeled and
> unlabeled parameters, and pattern matching user cases where the user does
> not wish to bind all of the arguments.
>
> Given `case foo(a: Int, String, b: Int, String)`, the only sensible
> interpretation of the rules for sugared syntax would allow the user to
> choose any name for some but not all of the labels. If the user wishes to
> bind only `b`, however, he or she will need to navigate a puzzling set of
> rules that are not spelled out in the proposal:
>
> ```
> case foo(a: _, _, b: let b, _)
> // this is definitely allowed
>
> case foo(a: _, _, b: let myVar, _)
> // this is also definitely allowed
>
> // but...
> case foo(_, _, b: let myVar, _)
> // is this allowed, or must the user explicitly state and not bind `a`?
>
> // ...and with respect to the sugared version...
> case foo(_, _, let b, _)
> // is this allowed, or must the user explicitly state and not bind `a`?
> ```
>
>
> Good point. To make up for this: `_` can substitute any sub pattern, which
> is something that this proposal doesn’t change but definitely worth
> spelling out.
>

This rule cannot hold. You cannot have the shorthand syntax you propose,
disallow mixing of shorthand syntax and the longer form, *and* allow `_` to
substitute for any pattern without a label.

```
enum E {
  case foo(a: Int, b: Int, c: Int)
  case foo(a: String, c: String, e: String)
}

let e = /* instance of E */

switch e {
case foo(let a, _, _):
  // what type is `a` here?
  break
default:
  fatalError()
}
```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170403/08b3f611/attachment.html>


More information about the swift-evolution mailing list