[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases
Chris Lattner
clattner at nondot.org
Fri Jan 12 01:28:00 CST 2018
> On Jan 11, 2018, at 9:26 PM, Gwendal Roué via swift-evolution <swift-evolution at swift.org> wrote:
>
> Hello,
>
>> Le 12 janv. 2018 à 02:36, Paul Cantrell via swift-evolution <swift-evolution at swift.org> a écrit :
>>
>> 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.
>
> A classic mantra on this mailing list is that stdlib protocols ought to come with generic use cases and algorithms.
While this is a good general goal, I don’t think this is an absolute requirement. As usual, I think the reality of the situation is more complicated:
While we generally generally steer protocols towards being a “bag of semantics” instead of a “bag of syntax”, there are definitely exceptions to that rule, including the ExpressibleBy and other compiler intrinsic protocols which really are *all about* defining syntax. These protocols are not particularly useful for generic algorithms.
The next level down are protocols like hashable/comparable that are useful for generic algorithms, but are also particularly interesting because of compiler synthesized conformances. They are unique because they are both sometimes interesting for generic algorithms, but also sometimes interesting just because you want the synthesized members on *concrete* types for non-generic uses. IMO, this is the bucket that this proposal falls into.
Finally, there is the “normal” user defined protocol case, which are clearly about defining the semantics of types and nothing more. Duck typing and “defined by syntax” conformance is clearly out of bounds for these.
-Chris
More information about the swift-evolution
mailing list