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

[Joshua Alvarado]

When would be a good time to resubmit this proposal for discussion? Or can
I still proceed with the review and it possibly gets deferred but at least
be put in the pipeline (if deferred)?

On Mon, Apr 24, 2017 at 9:07 AM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Apr 24, 2017, at 7:23 AM, T.J. Usiyan via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> /me Pushes implementation detail related concerns out of head
>
> +1
>
>
> I want this feature but I seriously doubt that it is feasible at the
> moment. There are so many 'more pressing' features that, even if this were
> accepted now, it wouldn't be implemented it in time for Swift 4.
>
>
> Out of scope for Swift 4, certainly. It may not look like it, but this is
> a fairly large feature. I suggest reading up on generalized algebraic
> data types <https://en.wikipedia.org/wiki/Generalized_algebraic_data_type> (GADTs),
> which is the more programming-language-theoretical name for what you’re
> describing here.
>
> - Doug
>
>
> That said, I would love to be incorrect.
>
> On Mon, Apr 24, 2017 at 9:57 AM, Joshua Alvarado via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> 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
>>    <https://github.com/lostatseajoshua/swift-evolution/blob/master/NNNN-enum-generic-cases.md>
>>    - Authors: Joshua Alvarado <https://github.com/alvaradojoshua0>
>>    - Review Manager: TBD
>>    - Status: PITCH
>>
>> *During the review process, add the following fields as needed:*
>>
>>    - Decision Notes: Rationale
>>    <https://lists.swift.org/pipermail/swift-evolution/>, Additional
>>    Commentary <https://lists.swift.org/pipermail/swift-evolution/>
>>    - Bugs: SR-NNNN <https://bugs.swift.org/browse/SR-NNNN>, SR-MMMM
>>    <https://bugs.swift.org/browse/SR-MMMM>
>>    - Previous Revision: 1
>>    <https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md>
>>    - Previous Proposal: SE-XXXX
>>    <https://github.com/lostatseajoshua/swift-evolution/blob/master/XXXX-filename.md>
>>
>>
>> <https://github.com/lostatseajoshua/swift-evolution/tree/master#introduction>
>> 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
>> <https://lists.swift.org/pipermail/swift-evolution/>
>>
>> <https://github.com/lostatseajoshua/swift-evolution/tree/master#motivation>
>> 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.
>>
>> <https://github.com/lostatseajoshua/swift-evolution/tree/master#proposed-solution>Proposed
>> solution
>>
>> The generic is to be casted on the case of the enum and not on the enum
>> itself.
>>
>> <https://github.com/lostatseajoshua/swift-evolution/tree/master#detailed-design>Detailed
>> design
>>
>> Current implementation:
>>
>> // enum with two generic typesenum Foo<T: Hashable, U: Collection> {
>>     case bar(obj: T)
>>     case baz(obj: U)
>> }
>> // U is to be casted but it is not even usedlet 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 enumvar foo1: Foo<String, [String]>?
>> // Collections don’t look great eithervar 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 Tvar foo: Foo = .bar(obj: "hash")
>> // doesn’t need to cast the generic on the optional enum// the associated value will hold the castvar foo1: Foo?
>> // This also gives better syntax with collections of enums with associated typesvar foos = [Foo]()
>> foos.append(.bar(obj: "hey")
>>
>>
>> <https://github.com/lostatseajoshua/swift-evolution/tree/master#source-compatibility>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.
>>
>> <https://github.com/lostatseajoshua/swift-evolution/tree/master#alternatives-considered>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
>> <https://github.com/lostatseajoshua/swift-evolution/blob/master/NNNN-enum-generic-cases.md>
>>
>> --
>> 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
>
>
>


-- 
Joshua Alvarado
alvaradojoshua0 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170424/ae8e0450/attachment.html>