[swift-evolution] [Pitch] Enum with generic cases

[jaden.geller at gmail.com]

I think the pattern match would have to introduce a new generic type variable within the match scope. Definitely not a simple feature, but GADTs would be so cool!

> On Apr 24, 2017, at 7:57 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> This is somehow similar to https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-constants.
> 
> Question, will pattern matching still work fine with that? I kinda fear that this won’t work in a different scopes, but feel free to prove me being wrong.
> 
> enum Foo {
>     case bar<T: Hashable>(obj: T)
>     case baz<U: Collection>(obj: U)
> }
> 
> struct Test {
>      
>     var foo: Foo = .bar(obj: "swift")
>      
>     func test() {
>          
>         switch self.foo {
>         case /* Check for `bar` and String */: …
>         case /* How to pattern match against `baz`? What is `U`? */: …
>          
>         // Do we need `default` everytime?
>         }
>     }
> }
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 24. April 2017 um 15:57:33, Joshua Alvarado via swift-evolution (swift-evolution at swift.org) schrieb:
> 
>> Here is my pitch on adding generics to enum cases and not to the enum type itself. Let me know if you have an improvements or modifications lets open it to discussion thank you swiftys! :)
>> Enum with generic cases
>> Proposal: SE-NNNN
>> Authors: Joshua Alvarado
>> Review Manager: TBD
>> Status: PITCH
>> During the review process, add the following fields as needed:
>> 
>> Decision Notes: Rationale, Additional Commentary
>> Bugs: SR-NNNN, SR-MMMM
>> Previous Revision: 1
>> Previous Proposal: SE-XXXX
>> Introduction
>> 
>> This proposal adds a change to the enumeration type that allows an enum case to cast a generic on its associated value.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> Enums currently support generics, but they are added onto the type itself. This can cause adverse syntax when implementing generics for associated values to be stored along each case. The enum case holds the associated value (not the enum type itself) so should create its own value constraints.
>> 
>> Proposed solution
>> 
>> The generic is to be casted on the case of the enum and not on the enum itself.
>> 
>> Detailed design
>> 
>> Current implementation:
>> 
>> // enum with two generic types
>> enum Foo<T: Hashable, U: Collection> {
>>     case bar(obj: T)
>>     case baz(obj: U)
>> }
>> 
>> // U is to be casted but it is not even used
>> let foo: Foo<String, [String]> = .bar(obj: "hash")
>> 
>> // Creating an optional enum, the generics have to be casted without a value set
>> // The casting is really not needed as the values should be casted not the enum
>> var foo1: Foo<String, [String]>?
>> 
>> // Collections don’t look great either
>> var foos = [Foo<String, [String]>]()
>> foos.append(.bar(obj:"hash"))
>> Proposed solution
>> 
>> enum Foo {
>>     case bar<T: Hashable>(obj: T)
>>     case baz<U: Collection>(obj: U)
>> }
>> 
>> // generic type inferred on T
>> var foo: Foo = .bar(obj: "hash")  
>> 
>> // doesn’t need to cast the generic on the optional enum
>> // the associated value will hold the cast
>> var foo1: Foo?  
>> 
>> // This also gives better syntax with collections of enums with associated types
>> var foos = [Foo]()
>> foos.append(.bar(obj: "hey")
>> Source compatibility
>> 
>> This may cause subtle breaking changes for areas in code with generic enum cases. The compiler could help with the change by finding the associated generic and updating the case with the new syntax.
>> 
>> Alternatives considered
>> 
>> An alternative would be to extend the associatedtype keyword to the enum type.
>> 
>> enum Foo {
>>     associatedtype T = Hashable
>>     case bar(obj: T)
>> }
>> 
>> Copy of proposal can be found here Swift proposal on github
>> 
>> --
>> Joshua Alvarado
>> alvaradojoshua0 at gmail.com
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170424/e7ac4617/attachment.html>