This looks pretty good! It might be worth calling out explicitly that matching a payloaded case by name alone still works, e.g.:
On Jan 23, 2017, at 11:38 AM, Daniel Duan <daniel@duan.org <mailto:daniel@duan.org>> wrote:
I’ve incorporated feedbacks from this thread.
Rendered: https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/NNNN-Normalize-Enum-Case-Representation.md
—
# Normalize Enum Case Representation
* Proposal: [SE-NNNN]
* Authors: [Daniel Duan], [Joe Groff]
* Review Manager: TBD
* Status: **Awaiting review**
## Introduction
In Swift 3, associated values for an enum case are represented by
a labeled-tuple. This has several undesired effects: inconsistency in enum value
construction syntax, many forms of pattern matching, missing features such as
specifying default value and missed opportunity for layout improvements.
This proposal aims to make enums more "regular" by replacing tuple as the
representation of associated values, making declaration and construction of enum
cases more function-like.
Swift-evolution thread: [Compound Names For Enum Cases][SE Thread]
## Motivation
**Each enum case declares a function that can be used to create a corresponding
value. To users who expect these functions to behave "normally", surprises
await.**
1. Associated value labels aren't part of the function name.
After [SE-0111] Swift function's fully qualified name consists of its
base-name and all argument labels. As an illustration, one can invoke
a function with its full name:
```swift
func f(x: Int, y: Int) {}
f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)
```
This, however, cannot be done when enum cases with associated value were
constructed:
```swift
enum Foo {
case bar(x: Int, y: Int)
}
Foo.bar(x: y:)(0, 0) // Does not compile as of Swift 3
```
Here, `x` and `y` are labels of bar's payload (a tuple), as opposed to being
part of the case's formal name. This is inconsistent with rest of the
language.
2. Default value for parameters isn't available in case declarations.
```swift
enum Animation {
case fadeIn(duration: TimeInterval = 0.3) // Nope!
}
let anim = Animation.fadeIn() // Would be nice, too bad!
```
**Associated values being a tuple complicates pattern matching.**
The least unexpected pattern to match a `bar` value is the following:
if case let .bar(x: p, y: q) = Foo.bar(x: 0, y: 1) {
print(p, q) // 0 1
}
In Swift 3, there are a few alternatives that may not be obvious to new users.
1. A pattern with a single value would match and result in a tuple:
```swift
if case let .bar(wat) = Foo.bar(x: 0, y: 1) {
print(wat.y) // 1
}
```
2. Labels in patterns are not enforced:
```swift
// note: there's no label in the following pattern
if case let .bar(p, q) = Foo.bar(x: 0, y: 1) {
print(p, q) // 0 1
}
```
These complex rules makes pattern matching difficult to teach and to expand to
other types.
**Moving away from tuple-as-associated-value also give us opportunity to improve
enum's memory layout** since each associated value would no longer play double
duty as part of the tuple's memory layout.
## Proposed Solution
When a enum case has associated values, they will no longer form a tuple. Their
labels will become part of the case's declared name. Patterns matching such
value must include labels in order matching the declaration.
This proposal also introduce the ability to include a default value for each
associated value in the declaration.
## Detailed Design
### Make associated value labels part of case's name
When labels are present in enum case's payload, they will become part of case's
declared name instead of being labels for fields in a tuple. In details, when
constructing an enum value with the case name, label names must either be
supplied in the argument list it self, or as part of the full name.
Foo.bar(x: 0, y: 0) // Okay, the Swift 3 way.
Foo.bar(x: y:)(0, 0) // Equivalent to the previous line.
Foo.bar(x: y:)(x: 0, y: 0) // This would be an error, however.
Note that since the labels aren't part of a tuple, they no longer participate in
type checking, similar to functions:
let f = Foo.bar // f has type (Int, Int) -> Foo
f(0, 0) // Okay!
f(x: 0, y: 0) // Won't compile.
### Add default value in enum case declarations
From a user's point view, declaring an enum case should remain the same as Swift
3 except now it's possible to add `= expression` after the type of an
associated value to convey a default value for that field. Updated syntax:
union-style-enum-case = enum-case-name [enum-case-associated-value-clause];
enum-case-associated-value-clause = "(" ")"
> "(" enum-case-associated-value-list ")";
enum-case-associated-value-list = enum-associated-value-element
> enum-associated-value-element ","
enum-case-associated-value-list;
enum-case-associated-value-element = element-name type-annotation
[enum-case-element-default-value-clause]
> type [enum-case-element-default-value-clause];
element-name = identifier;
enum-case-element-default-value-clause = "=" expression;
### Simplify pattern matching rules on enums
Syntax for enum case patterns will be the following:
enum-case-pattern = [type-identifier] "." enum-case-name [enum-case-associated-value-pattern];
enum-case-associated-value-pattern = "(" [enum-case-associated-value-list-pattern] ")";
enum-case-associated-value-list-pattern = enum-case-associated-value-list-pattern-element
> enum-case-associated-value-list-pattern-element ","
enum-case-associated-value-list-pattern;
enum-case-associated-value-list-element = pattern | identifier ":" pattern;
… and `case-associated-value-pattern` will be added to the list of various
`pattern`s.
Note that `enum-case-associated-value-pattern` is identical to `tuple-pattern`
except in names. It is introduced here to denote semantic difference between the
two. Whereas the syntax in Swift 3 allows a single `tuple-pattern-element` to
match the entire case payload, the number of
`enum-case-associated-value-list-pattern-element`s must be equal to that of
associated value of the case in order to be a match. This means this example
will be deprecated under this proposal:
if case let .bar(wat) = Foo.bar(x: 0, y: 1) { // syntax error
// …
}
Further, `identifier` in `enum-case-associated-value-list-pattern-element` must
be the same as the label of corresponding associated value intended for the
match. So this will be deprecated as well:
if case let .bar(p, q) = Foo.bar(x: 0, y: 1) { // missing `x:` and `y:`
// …
}
## Source compatibility
As detailed in the previous section, this proposal deprecates certain pattern
matching syntax.
Other changes to the syntax are additive and source compatible with Swift 3.
## Effect on ABI stability and resilience
After this proposal, enum cases may have compound names, which would be mangled
differently than Swift 3.
The compiler may also layout enums differently now that payloads are not
constrained by having to be part of a tuple.
## Alternative Considered
To maintain maximum source compatibility, we could introduce a rule that matches
all associated values to a labeled tuple. As T.J. Usiyan
[pointed out][TJs comment], implementation of the equality protocal would be
simplified due to tuple's conformance to `Equatable`. This feature may still be
introduced with alternative syntax (perhaps related to splats) later without
source-breakage. And the need to implement `Equatable` may also disappear with
auto-devriving for `Equitable` conformance.
A syntax that did stay for source compatibility is allowing `()` in patterns
that match enum cases without associated values:
if let case .x() = Foo.baz { // … }
We could remove this syntax as it would make the pattern look more consistent to
the case's declaration.
[SE-0111]: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
[Daniel Duan]: dduan (Daniel Duan) · GitHub
[Joe Groff]: jckarter (Joe Groff) · GitHub
[SE-NNNN]: NNNN-Normalize-Enum-Case-Representation.md
[TJs comment]: [swift-evolution] [draft] Compound Names For Enum Cases
[SE Thread]: [swift-evolution] [draft] Compound Names For Enum Cases
On Jan 19, 2017, at 10:37 AM, Daniel Duan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,
Here’s a short proposal for fixing an inconsistency in Swift’s enum. Please share you feedback :)
(Updating/rendered version: https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/NNNN-Compound-Names-For-Enum-Cases.md\)
## Introduction
Argument labels are part of its function's declaration name. An enum case
declares a function that can be used to construct enum values. For cases with
associated values, their labels should be part of the constructor name, similar
to "normal" function and methods. In Swift 3, however, this is not true. This
proposal aim to change that.
## Motivation
After SE-0111, Swift function's fully qualified name consists of its base name
and all argument labels. As a example, one can invoke a function with its
fully name:
func f(x: Int, y: Int) {}
f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)
This, however, is not true when enum cases with associated value were
constructed:
enum Foo {
case bar(x: Int, y: Int)
}
Foo.bar(x: y:)(0, 0) // Does not compile as of Swift 3
Here, the declared name for the case is `foo`; it has a tuple with two labeled
fields as its associated value. `x` and `y` aren't part of the case name. This
inconsistency may surprise some users.
Using tuple to implement associated value also limits us from certain layout
optimizations as each payload need to be a tuple first, as opposed to simply be
unique to the enum.
## Proposed solution
Include labels in enum case's declaration name. In the last example, `bar`'s
full name would become `bar(x:y:)`, `x` and `y` will no longer be labels in a
tuple. The compiler may also stop using tuple to represent associated values.
## Detailed design
When labels are present in enum cases, they are now part of case's declared name
instead of being labels for fields in a tuple. In details, when constructing an
enum value with the case name, label names must either be supplied in the
argument list it self, or as part of the full name.
Foo.bar(x: 0, y: 0) // Okay, the Swift 3 way.
Foo.bar(x: y:)(0, 0) // Equivalent to the previous line.
Foo.bar(x: y:)(x: 0, y: 0) // This would be an error, however.
Note that since the labels aren't part of a tuple, they no longer participate in
type checking, similar to functions:
let f = Foo.bar // f has type (Int, Int) -> Foo
f(0, 0) // Okay!
f(x: 0, y: 0) // Won't compile.
## Source compatibility
Since type-checking rules on labeled tuple is stricter than that on function
argument labels, existing enum value construction by case name remain valid.
This change is source compatible with Swift 3.
## Effect on ABI stability and resilience
This change introduces compound names for enum cases, which affects their
declaration's name mangling.
The compiler may also choose to change enum payload's representation from tuple.
This may open up more space for improving enum's memory layout.
## Alternatives considered
Keep current behaviors, which means we live with the inconsistency.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
. Will update the proposal and see how the rest of the feedback goes.