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 <cantr...@pobox.com> wrote:
>
>> On Jan 11, 2018, at 7:28 PM, Howard Lovatt <howard.lov...@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@swift.org> wrote:
>>>
>>>
>>>
>>>> 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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
