Proposal: Listing all possible values of a type

[beccadax]

This is a proposal for the long-discussed, frequently-requested, never-reviewed "give us a way to get all enum cases" feature.

[jessesquires]

Hey @brentdax ! 😄

How is this different from #114?

[beccadax]

Partly, #114 seems to have stalled and I thought the feature deserved a nudge. The two proposals are quite similar, but they do differ in minor but significant ways:

1. There is an underlying difficulty with both proposals: allValues should belong to an associated type conforming to Collection where .Iterator.Element == Self (to use the new terminology), but this cannot currently be expressed in Swift. The two proposals address this problem in different ways.
   1. In this proposal, allValues is defined in the protocol and is (perhaps temporarily) an Array<Self>. In Deriving collections of enum cases #114, allValues is not defined in the protocol, but is added to all types marked with the protocol, which means the protocol can't be used for generic programming. I believe it's more important to model the relationship; Deriving collections of enum cases #114 believes it's more important to have looser typing so that implementations can use more efficient collection types.
   2. In this proposal, the eventual change to the type of allValues is explicitly included as part of the proposal. In Deriving collections of enum cases #114, a workaround (the introduction of an AnyCollection<Element> type) is mentioned as a future direction. That's partly because this proposal was drafted after the Generics Manifesto, while Deriving collections of enum cases #114 was drafted before.
2. In this proposal, the semantic meaning of allValues is defined (for an Equatable type, all possible instances must == at least one of its elements; for other types, all possible instances must ~= at least one of its elements). Deriving collections of enum cases #114 makes no attempt to define this, which leaves its potential meaning for structs, classes, and protocols unclear.
3. In this proposal, the allValues property is defined to return values in their Comparable order if one is defined, or in source order otherwise. In Deriving collections of enum cases #114, the allValues property is defined to return values in source order. My way means that Swift will not be able to derive an allValues on Comparable enums unless it decides to somehow analyze the comparison operator's implementation; Deriving collections of enum cases #114's way means that the order is undefined for non-enum types.
4. This proposal sets minimum requirements for auto-deriving an allValues property, but allows derivation above that to be implementation-defined to avoid having to formally propose future extensions. Deriving collections of enum cases #114 specifically defines the enums which should have an allValues property derived and lists extensions of that capability as something to be added through the evolution process.
5. This proposal includes doc comments on the APIs it proposes. Deriving collections of enum cases #114 includes more discussion of alternatives and extensions.

In general, this proposal is more focused on defining the meaning of the ValueEnumerable protocol, while the automatic derivation of an allValues property is almost an afterthought. #114 is more focused on automatically deriving the allValues property, with the ValueEnumerable protocol primarily serving as a way to invoke that behavior.

I prefer my approach because I think the more specific semantics will serve us well in the future, but both of them will get us to similar places.

[jessesquires]

Ahh, I see.

I think it would be more productive and efficient to collaborate with @jtbandes on #114, discuss the differences on the mailing list (most recent response on the original thread here — from today), and then update #114 according to everyone's feedback. 😄

[jtbandes]

I'd be happy to discuss this further and update #114 if we can come up with something better. Please feel free to bring this up again on the mailing lists. I might not have enough time to contribute anything to the discussion in the next week or two, but I'll get back to it eventually.

[beccadax]

@jtbandes Let me know when you're a little less busy and I'll post something on the list. (Or just post it yourself.)

[jtbandes]

Re. 2: I'm happy to adopt your explanations of the semantic meaning, although we should think carefully about the wording, specifically usage of "must", if we're allowing users to write their own implementations (i.e. if allValues is exposed in the protocol).

Re. 4: I'm happy to adjust the wording to clarify that derivations not covered by the proposal are implementation-defined, but I'm skeptical that significant changes could be made without going through the evolution process.

Re. 5: That's a fairly minor point. I think we could combine them and offer both, or just drop the "future directions".

Re. the rest: I'm drafting an email to swift-evolution so we can keep discussing and hopefully come to some conclusions in the near future. I'll gladly share the draft with you, and I think it'll make sense to have both our names as co-authors on the proposal.