> On Jan 11, 2018, at 9:26 PM, Gwendal Roué via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Hello,
>> Le 12 janv. 2018 à 02:36, Paul Cantrell via swift-evolution 
>> <swift-evolution@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 

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.


swift-evolution mailing list

Reply via email to