> On Jan 10, 2018, at 10:21 PM, Chris Lattner via swift-evolution
> <swift-evolution@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
