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

[Jacob Bandes-Storch]

Thanks for the feedback, Brent! Responses inline:

On Mon, Jan 18, 2016 at 9:17 PM, Brent Royal-Gordon <brent at architechies.com>
wrote:
>
> >       • CaseEnumerable could have a user-visible declaration requiring
> static var cases, which would allow users to add conformances for custom
> non-enum types.
>
> I think this is an excellent idea. As Joe points out, this would imply
> that the protocol and property should have names which don't include the
> word "case". (Renaming is also a good idea because if the property is
> `cases`, you'll be tempted to say `for case in Foo.cases`, but `for case`
> will be misparsed.)
>
> Simply start the discussion, I suggest this definition:
>
>         /// Any type which can only take on one of a limited, easily
> enumerable list of values may
>         /// conform to FiniteType to make that list easy to access. For
> certain simple types,
>         /// Swift will automatically generate an implementation of
> `values`.
>         protocol FiniteType {
>                 /// A collection containing all possible values of this
> type.
>                 ///
>                 /// Invariant: T.values.contains(valueOfTypeT) for any
> valueOfTypeT. In other words, `values`
>                 /// must be truly exhaustive.
>                 static var values: ...
>         }
>

OK, I can see the argument here. I was worried about making this proposal
so broad that it wouldn't be seriously considered, but I agree that
choosing more general names will open it up to future expansion.

Here are some more name ideas:

- CaseEnumerable (in the proposal draft)
- T.cases (in the proposal draft)
- T.allCases
- FiniteType (as you suggested)
- FiniteValueType
- ValueEnumerable
- T.values
- T.allValues

Thoughts? More suggestions? I think I like ValueEnumerable.


>               • This would probably require cases to be
> AnySequence<Self>, or to introduce an AnyCollection, since we aren't able
> to say associatedtype CaseCollection: CollectionType where
> CaseCollection.Generator.Element == Self.
>
> Ouch, that's an ugly limitation. Is this going to change in Swift 3?
>

I can't speak to that. You might want to search the list to see if you can
find what's been said about the plan for Swift 3 generics so far.


> >       • It would be nice to have a way of supporting this for
> OptionSetType structs. I would recommend that cases for an OptionSetType
> should include only the already-declared static properties (not all
> possible combinations of them). However, I'm not sure it fits into this
> proposal.
>
> Theoretically, `cases` on an OptionSetType should return all combinations
> of options, so I think we'd need something different there.
>

As a user, I'd really love to be able to enumerate the individual "bits" of
an OptionSetType, such as all the NSWindow styleMask types: Borderless,
Titled, etc.  .cases or .values seems to be a natural place to return
those, but I guess you're right that these wouldn't really encompass
*all* possible
cases/values, so maybe it doesn't fit as well as I'd hope.

Is it too crazy to suggest synthesizing a collection of all the *static
members* of a type which are of type Self? This would cover enum cases and
OptionSetType fields.


>
> >       • Support for enum case names. It would be useful to get case
> names even for enums which have integer rawValues. This could be part of
> the existing reflection APIs, or it could take the form of derived
> implementations of StringLiteralConvertible/CustomStringConvertible.
>
> I very strongly believe this is a job for reflection, not for our case
> mechanism. (So, I agree with you.)
>

Playing devil's advocate: if handling names are a job for reflection, why
isn't getting all cases/values also a job for reflection?

Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160118/3017bf1b/attachment.html>