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

[Howard Lovatt]

I missed that sorry.

I think it will find other uses and therefore should be ValueEnumerable. 

-- Howard.

> On 11 Jan 2018, at 6:36 pm, Paul Cantrell <cantrell at pobox.com> wrote:
> 
>> On Jan 11, 2018, at 7:28 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
>> 
>> I am in favour of a protocol that you have to explicitly declare, it feels much more like Swift to me. For example you have to say Equatable explicitly. 
> 
> Howard — Either you’ve missed something or I have. I didn’t view requiring types to explicitly declare conformance as being up for debate at all.
> 
> The question I was weighing on it — what I thought Chris and Brent were discussing — was whether this new protocol should be used narrowly for cases of enums without associated types (which Chris favors), or whether it should find more broad use to mean “type which can enumerate all of its possible values” (which Brent finds interesting with caveats). This question has a bearing on whether the protocol’s name should be CaseEnumerable or ValueEnumerable.
> 
> In either case, the conformance is always explicitly declared; the compiler merely synthesizes the implementation for enums without associated types.
> 
> I think?
> 
>> As a contra example in Java it feels natural that the compiler just provides the functionality because that is consistent across the language, you don’t declare something as equatable and you don’t tell the compiler that you want the values array generating. 
>> 
>> ‘Horses for courses’, this is what Swift does. 
>> 
>> As a more hard-core example, suppose you want to use statics as an enum like construct, e.g.:
>> 
>>     struct Ex: ValueEnumerable {
>>         let x1: Int
>>         let x2: Int
>>         init(x1: Int, x2: Int) { self.x1 = x1, self.x2 = x2 }
>>         static let allValues = [x1, x2]
>>     }
>> 
>> Perhaps the above Ex started as an enum but was changed to a struct during enhancements to the program because the values of x1 and x2 are now read in rather than constants. 
>> 
>> -- Howard.
>> 
>>> On 11 Jan 2018, at 5:21 pm, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> 
>>>> 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
>>> 
>>> _______________________________________________
>>> 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/20180111/62bf8ba5/attachment.html>