Open Radar

 
Summary:
Enum cases can have associated values which can currently be accessed using a switch statement on the enum value and retrieving the appropriate values in each case.

In most cases this is great as the logic for handling the associated values might differ depending on the actual enum case anyway.

However, sometimes it might be useful to (read: easier to read & write) a general solution handling all cases equally. This is currently not possible as one cannot retrieve the associated values from an enum without switching over its cases.

A simple use case might be printing the associated values:

enum Foo {
    case Empty
    case Text(String)
    case Signed(Int)
    case Combination(String, Int)
    // ...
}

extension Foo : Printable {
    var description : String {
        // Example syntax
        return self.associatedValues.description

        // If enums provided more reflection features
        // return ".\(self.caseName)(\(self.associatedValues))"
    }
}


In this example, 'associatedValues' might return an array that would be:
* empty if in the .Empty case
* contain a String in the .Text case
* contain an Int in the .Signed case
* contain a String followed by an Int in the .Combined case
* etc...

Obviously the compiler might even infer the type of the array to the first common type of all possible values.

An alternative that fits better with the current enum syntax might be to return a n-ary tuple instead of an array, however that would require much more powerful tuples than are currently present (tuples of unknown size, features to get tuples size, members, member types, etc..) and would offer little benefit over the array version (I think).


The obvious downsides to this feature would be that it could (and probably would) be easily abused and result in uglier and unsafer code when used for more complex examples instead of the switch syntax. Another downside is of course increased language complexity.

What I am trying to say is, it might be nice to have but I am not sure if it would be worth the hassle :-) So I certainly won't mind if you decide this is not worth it.

However I would of course be delighted if you managed to come up with an even better solution :D

Steps to Reproduce:


Expected Results:


Actual Results:


Version:
Xcode 6 - Beta 3 (6A254o)
Swift version 1.0 (swift-600.0.38.7)
OS X 10.10 (14A283o)