[swift-evolution] Request: Ability to refer to an enum case in abstract (without its associated value)

Slava Pestov spestov at apple.com
Thu Dec 10 22:47:14 CST 2015


> On Dec 10, 2015, at 5:23 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Dec 10, 2015, at 5:19 PM, J. Cheyo Jimenez <cheyo at masters3d.com <mailto:cheyo at masters3d.com>> wrote:
>> 
>> //Swift version 2.2-dev
>> enum case 'CaseWithPayload' not found
> 
> Sorry, '.CaseWithPayload' was intended as a stand-in for whatever your specific case with payload is named:
> 
> enum Foo {
>   case A(Int)
>   case B
> }
> 
> let foo = Foo.A(0)
> 
> switch foo {
> case .A: print("hi")
> case .B: print("bye")
> }
> 
> -Joe

This discussion and the ‘List of all enum values’ thread makes me think of a related feature that most people probably aren’t aware of — referring to an enum case constructor for a case with a payload, without actually applying it, yields a function value that you can pass around, eg in the above code ‘Foo.A’ has type Int -> Foo.

In the past we’ve also talked about adding ‘projections’ which test for that enum case and wrap the payload in an optional, where Foo.A would have two overloads, the constructor Int -> Foo and a projection Foo -> Int?.

It might be useful for enum cases to witness protocol requirements, too — has anyone wanted this?

Just food for thought,

Slava

> 
>> 
>> 
>> 
>> On Thu, Dec 10, 2015 at 3:31 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Dec 10, 2015, at 2:05 PM, Evan Maloney via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I'm not sure if this is what you're driving at, but I've found a use-case for the ability to refer to an enum case generically without reference to any of its associated values.
>>> 
>>> Let me give you an example:
>>> 
>>> In our app, we have an enum that represents all the different screens to which the user can navigate. (A screen in our case usually means a view controller or hierarchy thereof.)
>>> 
>>> Because each screen might require specific view model object(s) to render their content, some of our enum cases have associated values to store the required view model objects.
>>> 
>>> This allows an enum value to contain all the information needed to present any screen to the user, fully populated with content.
>>> 
>>> However, in a few instances I've found it would be helpful to be able to refer to a screen in the abstract and be able to 'switch' against it without any associated values. (This would allow me to be able to refer to, say, "the User Account screen" in the abstract, whereas now I can only refer to "the User Account screen displaying details for this particular user".)
>> 
>> I might be missing something, but you can do this already. 'case .CaseWithPayload:' matches any CaseWithPayload regardless of its payload.
>> 
>> -Joe
>> 
>>> We've identified two possible solutions to this issue and have implemented one of them, but it is still sub-optimal:
>>> 
>>> • One option involves maintaining a parallel enum with the same case names but without any associated values. These parallel structures need to be manually maintained, which is something the compiler cannot enforce.
>>> 
>>> • Another option involves removing the associated values from the enum and passing around objects to contain the necessary view model objects. At various points, we assert that the view model container object is of the expected type for the enum case, but again, that now moves to runtime an error that otherwise would've been caught by the compiler.
>>> 
>>> ---
>>> 
>>> When an enum case takes one or more associated values, it acts more like a type than a value because it specifies a format for storing information without specifying the exact informations stored. We're able to refer to other types as such in Swift, but not in this case.
>>> 
>>> I think it would be helpful if any enum with at least one case had a parallel representation containing the same cases but without associated values. It might look like:
>>> 
>>> enum Foo
>>> {
>>>     case Bar(String)
>>>     case Baz(Int, Int)
>>> 
>>>     // generated by the compiler; returns the parallel FooType
>>>     // with cases that don't have associated values
>>>     var enumType: FooType
>>> }
>>> 
>>> // generated by the compiler when an enum
>>> // has at least one associated value
>>> enum FooType
>>> {
>>>     case Bar
>>>     case Baz
>>> }
>>> 
>>> This would make it possible to be able to refer to cases in the abstract.
>>> 
>>> Perhaps there's a totally different solution to this class of problem, but that's what I came up with. Would love to hear your thoughts.
>>> 
>>> E.
>>> 
>>> 
>>> 
>>>> On Dec 10, 2015, at 8:24 AM, plx via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> FWIW, as long as we’re asking for some compiler assistance generating useful enumeration-related boilerplate, I’d like to request that something along these lines be possible in some version of Swift:
>>>> 
>>>> @synthesize_case_enum
>>>> enum Example {
>>>> 
>>>>  case Foo(X)
>>>>  case Bar
>>>>  case Baz(Y)
>>>> 
>>>> }
>>>> 
>>>> …which would then by default expand to something like this:
>>>> 
>>>> enum ExampleCase : Int {
>>>> 
>>>>  case Foo
>>>>  case Bar
>>>>  case Baz
>>>> 
>>>> }
>>>> 
>>>> extension Example {
>>>> 
>>>>  var enumerationCase: ExampleCase {
>>>>    get {
>>>>      switch self {
>>>>        case .Foo(_): return .Foo
>>>>        case .Bar(_): return .Bar
>>>>        case .Baz(_): return .Baz
>>>>      }
>>>>    }
>>>>  }  
>>>> 
>>>> }
>>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/7cf186c3/attachment.html>


More information about the swift-evolution mailing list