[Draft] Anonymous Enum Cases

dduan · March 9, 2017, 3:09am

Hi all,

During review for the first revision of SE-0155, Dave Abraham suggested that we should allow enum cases without base names. So here’s a (rough) draft of a proposal for this feature. Please read and share your thoughts!

# Anonymous Enum Cases

* Proposal: [SE-NNNN](NNNN-anonymous-enum-cases.md)
* Authors: [Daniel Duan](https://github.com/dduan\)
* Review Manager: TBD
* Status: **Awaiting review**

## Introduction

This proposal adds anonymous cases to Swift's enum.

## Motivation

Naming things is a tough task for programmer. This is one merit of features such
as anonymous function and tuples: users can use them in a limited scope and skip
the mind burden of coming up with names. We can expand this convenience to enums
by allowing user to declare, construct and pattern match anonymous cases.

## Proposed solution

Add anonymous cases to Swift's enum.

## Detailed design

Anonymous enums can be declared with this syntax:

enum Foo {
    case (Int)
    case (label0: Int, label1: String)
}

Anonymous case without any associated values is not allowed.

Anonymous case values can be constructed with constructors with the enum's name
being their base name. Following the example:

Foo(42) // constructs `Foo` case corresponding to `case (Int)`
Foo(label0: 0, labe1: "hello") // value of type Foo, 2nd case.
Foo(label0: label1:)(0, "hello") // constructs the same value, SE-0155 syntax

For pattern matching, rules remain the same as regular cases, execpt, naturally,
the base name shall be skipped.

case .(let x) = Foo(42) // x has value 42
case .(label0: let a, label1: let b) = Foo(label0: 0, label1: "hello") // ok

## Source compatibility

This is additive. It's fully source compatible with Swift 3.

## Effect on ABI stability

This feature adds new possibilities to symbols exposed by enum declarations.

## Effect on API resilience

## Alternatives considered

It may seem "regular" to make user use `_` in place of base name in
declarations. The author think that's a perspective that only makes sense for
language designer/compiler implementors. To a user, the syntax chosen in this
proposal is clear and succinct.

DevAndArtist · March 9, 2017, 6:29am

Iff we can omit Foo constructor for let x: Foo = 42 then I’d give it +1

One could also completely fall back and construct these enums with labeled tuples:

let a: Foo = 42 // constructs `Foo` case corresponding to `case (Int)`
let b: Foo = (label0: 0, labe1: "hello") // value of type Foo, 2nd case.
The former is needed for types like Either<A, B>.

You could also add some kind of an attribute to an enum case with an associated value to allow implicit case anonymity, iff it’s not ambiguous with the other cases of the same enum.

enum MyEnum {

     @anonymous case string(String)
     @anonymous case integer(Int)
     case boolean(Bool)
}

let a: MyEnum = "foo" // implicit
let b: MyEnum = 42 // implicit
let c: MyEnum = .string("test") // explicit
let d: MyEnum = .boolean(true) // always explicit because that case is not anonymous

···

--
Adrian Zubarev
Sent with Airmail

Am 9. März 2017 um 04:09:48, Daniel Duan via swift-evolution (swift-evolution@swift.org) schrieb: