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

Jacob Bandes-Storch jtbandes at gmail.com
Tue Jan 19 14:20:29 CST 2016

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>

More information about the swift-evolution mailing list