Working with enums by name


(Leonardo Pessoa) #1

Since we're talking a lot enums these days, I'd like to bring into
discussion a proposal that has been briefly mentioned in another
thread to enable working with enums using their names.

This is currently possible in the language but it's a bit burdensome.
You can just interpolate the value of the enum into a string to get
its name/representation as a string but you have to write case by case
the init methods for each enum to convert the string back to its
value. For example:

  enum Planet : Int {
     case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune

     init?(caseName name : String) {
         switch name {
             case "Mercury":
                 self = .Mercury
             case "Venus":
                 self = .Venus
             case "Earth":
                 self = .Earth
             case "Mars":
                 self = .Mars
             case "Jupiter":
                 self = .Jupiter
             case "Saturn":
                 self = .Saturn
             case "Uranus":
                 self = .Uranus
             case "Neptune":
                 self = .Neptune
             default:
                 return nil
         }
     }
  }

  let planet = Planet(caseName: "Earth")!
  print("\(planet) = \(planet.rawValue)") // Earth = 3

My proposal here is to let the compiler create these initialisers
automatically, just like with rawValue.

The reasoning here is simple: Enums in their basics are values, like
Int values or Double values, but limited to a closed set and
referenced in code by a name. Although they *may* have raw value
equivalents not all do (they don't need to). Using the name of the
enum value instead of any value associated with it also benefits
persistence since these associated values can change overtime while
the name is less likely to change.

As an example of the importance of this proposal, I mention the
company I work for who chooses to store (DB) the names of enum values
where they are used in persisted data arguing it's easier to debug and
support, and several web services we work with send enumerated values
as the strings of their names which we have to convert back to the
enum value when we receive. This proposal would simplify writing such
parts of the apps.

In case you're thinking, enums with associated values can also have
their instances created this way because there seems to be a default
representation for them in string interpolation. It's possible to be
done manually but would require a lot more of code and effort to be
converted back:

  enum Platform {
     case OSX(version: String)
     case iOS(version : Int)
  }

  let plat = Platform.iOS(version: 9)
  print("\(plat)") // iOS(9)

  let plat2 = Platform.OSX(version: "10.10.4")
  print("\(plat2)") // OSX("10.10.4")

Furthermore, I'm aware the output of the string interpolation may be
altered by adopting certain protocols so it should also be interesting
for this proposal to add a property like .caseName to all enums to
ensure the correct string representation that would be converted back
to the enum value.

I'd like to hear your opinions before writing a proposal.
Thanks.

L


(Brent Royal-Gordon) #2

> enum Planet : Int {
> case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
>
> init?(caseName name : String) {

The compiler actually does this already through RawRepresentable if you put `String` as your raw type. So what's the use case for this? Code which needs both a non-String rawValue *and* needs to look up cases by name? How common do you think that is?

···

--
Brent Royal-Gordon
Architechies


(Paul Cantrell) #3

How about a LogCategory enum:

• whose name is printed with each log entry (and thus wants a String raw type),
• which can be configured from command line or config file (and thus wants string-based lookup), but
• also wants OptionSetType-like behavior (and thus an Int raw type).

P

···

On May 31, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

> enum Planet : Int {
> case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
>
> init?(caseName name : String) {

The compiler actually does this already through RawRepresentable if you put `String` as your raw type. So what's the use case for this? Code which needs both a non-String rawValue *and* needs to look up cases by name? How common do you think that is?


(Leonardo Pessoa) #4

Don't you think it's a bit of a waste to be repeating the name of the value as a string just to use init(rawValue:) with them? What if I need to store another string associated with the value of the enum e.g. I want to create an enum to represent options in a menu and the associated value is to be the name of the image file to be used for that option? I don't know how common that is, but I don't see how good it is for you to keep repeating yourself in your code when the value you want and need is right by your side (DRY principle) and can be used easily in one way (to string) but not the other (back to enum).

L

···

On 31 May 2016, at 6:48 pm, Brent Royal-Gordon <brent@architechies.com> wrote:

> enum Planet : Int {
> case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
>
> init?(caseName name : String) {

The compiler actually does this already through RawRepresentable if you put `String` as your raw type. So what's the use case for this? Code which needs both a non-String rawValue *and* needs to look up cases by name? How common do you think that is?

--
Brent Royal-Gordon
Architechies


(Brent Royal-Gordon) #5

• also wants OptionSetType-like behavior (and thus an Int raw type).

Then it's not an `enum`, it's a `struct`.

···

--
Brent Royal-Gordon
Architechies


(Austin Zheng) #6

If we had generic protocols, you could implement RawRepresentable twice,
once using Ints and one using Strings. But that's probably never going to
happen.

/digression

Austin

···

On Tue, May 31, 2016 at 3:11 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

> On May 31, 2016, at 4:07 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> • also wants OptionSetType-like behavior (and thus an Int raw type).
>
> Then it's not an `enum`, it's a `struct`.

You can get it for free as an array of enums and test with contains vs
member

-- E, who has probably digressed more than she really should
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #7

You can get it for free as an array of enums and test with contains vs member

-- E, who has probably digressed more than she really should

···

On May 31, 2016, at 4:07 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

• also wants OptionSetType-like behavior (and thus an Int raw type).

Then it's not an `enum`, it's a `struct`.


(Brent Royal-Gordon) #8

Don't you think it's a bit of a waste to be repeating the name of the value as a string just to use init(rawValue:) with them?

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
  1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune }
  2> Planet.mercury.rawValue
$R0: String = "mercury"

What if I need to store another string associated with the value of the enum e.g. I want to create an enum to represent options in a menu and the associated value is to be the name of the image file to be used for that option?

Use the instance as a key into a dictionary of images. (Or use the rawValue as a key into a plist dictionary of image names. Or just name the image after the rawValue.)

In any case, this sounds like we're back to your other thread, the one about attaching properties to cases. That's a great feature, but it's a different feature from this one.

···

--
Brent Royal-Gordon
Architechies


(Leonardo Pessoa) #9

If I got the idea right, you would need to implement yourself the protocol methods to answer for both init(rawValue: Int) and init(rawValue: String) - which is how you have to do today only with the string part - while my proposed approach you'd have to implement nothing yourself.

L

···

On 31 May 2016, at 7:19 pm, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

If we had generic protocols, you could implement RawRepresentable twice, once using Ints and one using Strings. But that's probably never going to happen.

/digression

Austin

On Tue, May 31, 2016 at 3:11 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

> On May 31, 2016, at 4:07 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
>
>> • also wants OptionSetType-like behavior (and thus an Int raw type).
>
> Then it's not an `enum`, it's a `struct`.

You can get it for free as an array of enums and test with contains vs member

-- E, who has probably digressed more than she really should
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Patrick Smith) #10

I had no idea you could do this!!

···

On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune }
2> Planet.mercury.rawValue
$R0: String = "mercury"


(Brent Royal-Gordon) #11

This is, however, kind of a hack IMHO that relies on the compiler behavior that isn’t well documented.

It’s documented in “The Swift Programming Language”, in the same paragraphs where the enum Planet example we’ve been working with comes from.

“When you’re working with enumerations that store integer or string raw values, you don’t have to explicitly assign a raw value for each case. When you don’t, Swift will automatically assign the values for you.

“When strings are used for raw values, the implicit value for each case is the text of that case’s name.”

···


Brent Royal-Gordon
Architechies


(Leonardo Pessoa) #12

Yes, you can do all this but you still have to do everything yourself by hand. Dictionary, plist, it even init as my initial example but you are the one responsible to control when e.g. you add a new value or rename another.

My proposal causes no big changes and no big overload on the compiler; it just adds an init method to find the equivalent enum value for a string. And yes this feature becomes a lot more interesting should the idea of using tuple typed enums goes forward but they are completely independent.

L

···

-----Original Message-----
From: "Patrick Smith" <pgwsmith@gmail.com>
Sent: ‎01/‎06/‎2016 04:52 AM
To: "Brent Royal-Gordon" <brent@architechies.com>
Cc: "Leonardo Pessoa" <me@lmpessoa.com>; "Swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Working with enums by name

I had no idea you could do this!!

On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune }
2> Planet.mercury.rawValue
$R0: String = "mercury"


(Leonardo Pessoa) #13

In this case of not using raw values in an enum, can you use init(rawValue:) as in my proposal?

L

···

-----Original Message-----
From: "Charlie Monroe via swift-evolution" <swift-evolution@swift.org>
Sent: ‎01/‎06/‎2016 07:19 AM
To: "Brent Royal-Gordon" <brent@architechies.com>
Cc: "Swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Working with enums by name

Sorry, must've missed that.

On Jun 1, 2016, at 12:17 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

This is, however, kind of a hack IMHO that relies on the compiler behavior that isn't well documented.

It's documented in "The Swift Programming Language", in the same paragraphs where the `enum Planet` example we've been working with comes from.

“When you’re working with enumerations that store integer or string raw values, you don’t have to explicitly assign a raw value for each case. When you don’t, Swift will automatically assign the values for you.
<snip>
“When strings are used for raw values, the implicit value for each case is the text of that case’s name.”

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Leonardo Pessoa) #14

Just a fix. I've just tried the following code and the compiler complained there is no .rawValue on the type.

  enum Size { case Fit, Fill }
  print(Size.Fit.rawValue)

Then, as I said before, you can only get the value name as a string from interpolation and need to do everything by hand the other way around.

L

···

-----Original Message-----
From: "Charlie Monroe via swift-evolution" <swift-evolution@swift.org>
Sent: ‎01/‎06/‎2016 07:19 AM
To: "Brent Royal-Gordon" <brent@architechies.com>
Cc: "Swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Working with enums by name

Sorry, must've missed that.

On Jun 1, 2016, at 12:17 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

This is, however, kind of a hack IMHO that relies on the compiler behavior that isn't well documented.

It's documented in "The Swift Programming Language", in the same paragraphs where the `enum Planet` example we've been working with comes from.

“When you’re working with enumerations that store integer or string raw values, you don’t have to explicitly assign a raw value for each case. When you don’t, Swift will automatically assign the values for you.
<snip>
“When strings are used for raw values, the implicit value for each case is the text of that case’s name.”

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Leonardo Pessoa) #15

This should work but feels like an ugly hack to me. What if I needed
the enum like this?

  enum Size : Double {
      case Fit = 0.5
      case Fill = 3.0
  }

Then I can no longer rely on the compiler to fill string raw values
for me to use.

L

···

On 1 June 2016 at 07:59, Vladimir.S <svabox@gmail.com> wrote:

Try this:

enum Size: String { case Fit, Fill }
print(Size.Fit.rawValue)

On 01.06.2016 13:42, Leonardo Pessoa via swift-evolution wrote:

Just a fix. I've just tried the following code and the compiler complained
there is no .rawValue on the type.

> enum Size { case Fit, Fill }
> print(Size.Fit.rawValue)

Then, as I said before, you can only get the value name as a string from
interpolation and need to do everything by hand the other way around.

L

---------------------------------------------------------------------------
From: Charlie Monroe via swift-evolution
<mailto:swift-evolution@swift.org>
Sent: ‎01/‎06/‎2016 07:19 AM
To: Brent Royal-Gordon <mailto:brent@architechies.com>
Cc: Swift-evolution <mailto:swift-evolution@swift.org>

Subject: Re: [swift-evolution] Working with enums by name

Sorry, must've missed that.

On Jun 1, 2016, at 12:17 PM, Brent Royal-Gordon <brent@architechies.com> >> >> wrote:

This is, however, kind of a hack IMHO that relies on the compiler

behavior that isn't well documented.

It's documented in "The Swift Programming Language", in the same

paragraphs where the `enum Planet` example we've been working with comes
from.

“When you’re working with enumerations that store integer or string raw

values, you don’t have to explicitly assign a raw value for each case.
When
you don’t, Swift will automatically assign the values for you.

<snip>
“When strings are used for raw values, the implicit value for each case

is the text of that case’s name.”

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Paul Cantrell) #16

IIRC, string interpolation prepends the module name if the enum belongs to a module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of compiler crashes, at least in the past.

Those two factors forced me into this ugliness: https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115

A clean, documented, supported way of exposing the enum case name that the runtime clearly already has available seems sensible — and should be independent of the raw type.

Cheers, P

···

On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

This is, however, kind of a hack IMHO that relies on the compiler behavior that isn't well documented.

For example, this:

enum Planet {
  case Earth
  case Mars
}

"\(Planet.Mars)" // This is "Mars"

Works as well. You don't need to have the represented value to be String.

Note that this:

- works both when you have a plain enum, or enum Planet: Int, or whatever raw value kind
- does not work (!) when declared as @objc - then the result is "Planet".

On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org> wrote:

I had no idea you could do this!!

On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune }
2> Planet.mercury.rawValue
$R0: String = "mercury"

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charlie Monroe) #17

This is, however, kind of a hack IMHO that relies on the compiler behavior that isn't well documented.

For example, this:

enum Planet {
  case Earth
  case Mars
}

"\(Planet.Mars)" // This is "Mars"

Works as well. You don't need to have the represented value to be String.

Note that this:

- works both when you have a plain enum, or enum Planet: Int, or whatever raw value kind
- does not work (!) when declared as @objc - then the result is "Planet".

···

On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org> wrote:

I had no idea you could do this!!

On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune }
2> Planet.mercury.rawValue
$R0: String = "mercury"

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charlie Monroe) #18

Sorry, must've missed that.

···

On Jun 1, 2016, at 12:17 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

This is, however, kind of a hack IMHO that relies on the compiler behavior that isn't well documented.

It's documented in "The Swift Programming Language", in the same paragraphs where the `enum Planet` example we've been working with comes from.

“When you’re working with enumerations that store integer or string raw values, you don’t have to explicitly assign a raw value for each case. When you don’t, Swift will automatically assign the values for you.
<snip>
“When strings are used for raw values, the implicit value for each case is the text of that case’s name.”

--
Brent Royal-Gordon
Architechies


(Leonardo Pessoa) #19

Paul, in all my tests for this thread printing the enum value only
produced the enum value's name ("Mars" in your example). The proposal
of having a .caseName (or should it better be .caseValue to cover
enums with associated values? any other suggestions?) will prevent
that changes to this behaviour crash apps in the future as this should
always produce the same result even if the string representation
changes.

L

···

On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution <swift-evolution@swift.org> wrote:

IIRC, string interpolation prepends the module name if the enum belongs to a module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of compiler crashes, at least in the past.

Those two factors forced me into this ugliness: https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115

A clean, documented, supported way of exposing the enum case name that the runtime clearly already has available seems sensible — and should be independent of the raw type.

Cheers, P

On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

This is, however, kind of a hack IMHO that relies on the compiler behavior that isn't well documented.

For example, this:

enum Planet {
      case Earth
      case Mars
}

"\(Planet.Mars)" // This is "Mars"

Works as well. You don't need to have the represented value to be String.

Note that this:

- works both when you have a plain enum, or enum Planet: Int, or whatever raw value kind
- does not work (!) when declared as @objc - then the result is "Planet".

On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org> wrote:

I had no idea you could do this!!

On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune }
2> Planet.mercury.rawValue
$R0: String = "mercury"

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Christopher Kornher) #20

Indeed, you’re quite right: verified that I get “Mars” even when the enum is in a framework.

It took a little digging to get back what I was thinking of: it’s when the enum value is inside some other data structure that you get an annoyingly fully qualified name:

    enum CoinSide {
        case heads
        case tails
    }

    enum CoinState {
        case inAir
        case landed(showing: CoinSide)
    }

    print(CoinState.inAir) // → "inAir"

    // …but…

    print(CoinState.landed(showing: .heads)) // → "landed(CoinSide.heads)"

    print([CoinSide.heads: 1]) // → "[CoinSide.heads: 1]"

This is the case I was thinking of where the module name comes into play. Drop those enums into a framework, and you’ll get "landed(MyFramework.CoinSide.heads)". Ugh!

This seems to be more of namespace “import” issue than a problem with enums specifically. Declaring enums within another entity is a useful. I take advantage of qualified naming to make short, possibly non-unique enum names.

···

On Jun 1, 2016, at 12:53 PM, Paul Cantrell via swift-evolution <swift-evolution@swift.org> wrote:

So what if you want those second two to print out as "landed(heads)" and "[heads: 1]”? This does not work:

    enum CoinSide: CustomStringConvertible {
        case heads
        case tails
        
        var description: String {
            return String(self) // infinite recursion
        }
    }

There’s no automatically implemented description (or debugDescription) property we can delegate to. The conversion of .heads → "heads" is apparently runtime magic that we lose access to as soon as we implement CustomStringConvertible or CustomDebugStringConvertible, and therefore AFAIK there's no way to do this other than switching on all the cases:

    enum CoinSide: CustomStringConvertible {
        case heads
        case tails
        
        var description: String {
            switch(self) {
                case heads: return "heads"
                case tails: return "tails"
            }
        }
    }

Is is true that there’s no better way? Is there some CustomVerboseDebugStringConvertible protocol we can override to change only the "MyFramework.CoinSide.heads" form?

If indeed there is no better way, it seems like a really good case for having the synthesized .caseName property. Even if there is a CustomVerboseDebugStringConvertible to override in the particular case above, being able to customize an enum’s description but still use the enum case name in that description seems like a compelling use case as well.

Cheers, P

On Jun 1, 2016, at 10:47 AM, Leonardo Pessoa <me@lmpessoa.com <mailto:me@lmpessoa.com>> wrote:

Paul, in all my tests for this thread printing the enum value only
produced the enum value's name ("Mars" in your example). The proposal
of having a .caseName (or should it better be .caseValue to cover
enums with associated values? any other suggestions?) will prevent
that changes to this behaviour crash apps in the future as this should
always produce the same result even if the string representation
changes.

L

On 1 June 2016 at 12:15, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

IIRC, string interpolation prepends the module name if the enum belongs to a module: “MyLib.Mars” instead of just “Mars”. It’s also been a source of compiler crashes, at least in the past.

Those two factors forced me into this ugliness: https://github.com/bustoutsolutions/siesta/blob/master/Source/ResourceObserver.swift#L106-L115

A clean, documented, supported way of exposing the enum case name that the runtime clearly already has available seems sensible — and should be independent of the raw type.

Cheers, P

On Jun 1, 2016, at 5:10 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

This is, however, kind of a hack IMHO that relies on the compiler behavior that isn't well documented.

For example, this:

enum Planet {
     case Earth
     case Mars
}

"\(Planet.Mars)" // This is "Mars"

Works as well. You don't need to have the represented value to be String.

Note that this:

- works both when you have a plain enum, or enum Planet: Int, or whatever raw value kind
- does not work (!) when declared as @objc - then the result is "Planet".

On Jun 1, 2016, at 9:52 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org> wrote:

I had no idea you could do this!!

On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance.
1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune }
2> Planet.mercury.rawValue
$R0: String = "mercury"

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution