[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Paul Cantrell]

> On Jan 10, 2018, at 10:21 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Brent, thanks for the detailed response, one question about it:
> 
>> On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> But that's beside the point. What I think the "`allValues` should be allowed to be infinite" suggestion misses is that one of `ValueEnumerable`'s semantics is that it's not only theoretically *possible* to enumerate all the values, but actually *reasonable* to do so.
> ...
>> Some types, of course, fall into a gray area. `Int8` is fairly reasonable, but larger integer types get increasingly unreasonable until, by `Int64`, we reach types that would take decades to enumerate. Where the line should be drawn is a matter of opinion. (My opinion, to be clear, is that we shouldn't conform any of them; if someone really wants to do it, they can add a retroactive conformance.)
> 
> I’m not sure which way you’re arguing here, but that’s ok. :-)
> 
> In my opinion, while I can see where you are coming from (that it could be “reasonable” to allow random types to be ValueEnumerable) I don’t see what the *utility* or *benefit* that would provide.
> 
> If we went with a simpler design - one that named this CaseEnumerable and .allCases - we would be heavily biasing the design of the feature towards enum-like applications that do not have associated types.  This is “the” problem to be solved in my opinion, and would lead to a more clear and consistently understood feature that doesn’t have the ambiguity and “gray areas” that you discuss above.  Given this bias, it is clear that infinite sequences are not interesting.
> 
> Of course it would certainly be *possible* for someone to conform a non-enum-like type to CaseEnumerable, but that would be an abuse of the feature, and not a "gray area”.  
> 
> 
> Is there some specific *utility* and *benefit* from creeping this feature beyond “enumerating cases in enums that don’t have associated types”?  Is that utility and benefit large enough to make it worthwhile to water down the semantics of this protocol by making it so abstract?

I gave an example in my review of an enumerable thing where the items are analogous to cases but are not actually cases, and where I thought `allCases` would cause confusion but `allValues` would make sense:

> On Jan 10, 2018, at 10:22 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:

> 

> Contra Chris, I slightly prefer ValueEnumerable, because it extends to situations where we still want to enumerate a fixed set of possibilities which don’t strictly correspond to enum cases but still have that sort of flavor. For example, one might want:
> 
>     enum SideOfBody
>       {
>       case left
>       case right
>       }
> 
>     enum Limb: ValueEnumerable
>       {
>       case arm(SideOfBody)
>       case leg(SideOfBody)
> 
>       static let allValues =
>         [
>         arm(.left),
>         arm(.right),
>         leg(.left),
>         leg(.right)
>         ]
>       }
> 
> To my eyes, this code reads better than it would with CaseEnumerable / allCases.

This raises a question related to Chris’s: what is the utility of having Limb conform to a protocol instead of just providing allValues ad hoc? Does CaseEnumerable / ValueEnumerable serve any purpose other than triggering special behavior in the compiler? Would the protocol ever be used as the type of something in code?

My answers, admittedly weak ones, are: (1) conventions are nice and consistency is nice, and (2) you never know how an abstraction might be used, but you do know that people will be angry when it should fit but doesn’t. I can’t come up with a more compelling or specific argument than those.

Cheers,

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180111/b32f2def/attachment.html>