[swift-evolution] Pre-proposal: CaseEnumerable protocol (derived collection of enum cases)

[Jacob Bandes-Storch]

Would you agree that it makes sense to:

1. Automatically derive CaseEnumerable (or ValueEnumerable or whatever we
choose) for Swift enums without associated values;
2. Still allow "extension Foo: CaseEnumerable {}" to add it to enums
imported from (Obj-)C headers?

Or is it OK as-is, or is it worth pursuing some kind of "deriving" syntax?

Jacob Bandes-Storch

On Tue, Jan 19, 2016 at 12:17 PM, Joe Groff <jgroff at apple.com> wrote:

> The compiler implicitly derives T: Equatable for enums without associated
> values, and IMO it'd be reasonable to extend this to other types and/or
> other protocols.
>
> -Joe
>
> On Jan 19, 2016, at 11:37 AM, David Waite via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> ErrorType’s magic is only for Objective-C interoperability, and only
> exposed by diving into compiler implementation-level protocols.
>
> This seems like a case where some syntax consistency is needed between
> ‘code generation’ proposals (such as member wise initializers). If there
> was guidance on what an eventual macro system syntax could look like, this
> could be taken into account as well.
>
> -DW
>
> On Jan 19, 2016, at 11:36 AM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Yes: ErrorType.
>
> On Tue, Jan 19, 2016 at 10:21 AM, Sune Foldager <cyano at me.com> wrote:
>>
>>>
>>> Hm, I don’t think I like that. Are there other examples of magic
>>> protocols in Swift?
>>>
>> _______________________________________________
> 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/20160119/4ed63156/attachment.html>