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 > <[email protected]> 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 > ([email protected]) 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 >> [email protected] >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
