On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution 
<swift-evolution@swift.org> wrote:
> My objection to the "ValueEnumerable" design--especially in its generalized 
> form here (versus "CaseEnumerable")--is that the protocol's semantics (and, 
> we'll recall, protocols in Swift must offer semantics that make possible 
> useful generic algorithms) are so broad as to be little more than essentially 
> what it means to be a type.

Thank you for writing this up Xiaodi.  I completely agree with you that 
“CaseEnumerable” is a better name for this: it is more specific and purposeful 
and make it more clear what the purpose and scope is.

Your later suggestion of “Enumerable” seems to broad and potentially confusing 
to me.  Tying it to the things that are being enumerated (enum cases) seems 
more purposeful.

> Brent just wrote that he might later propose to extend `ValueEnumerable` to 
> `Bool` and `Optional`,

To be fair, Optional *is* an enum, and Bool really should be (we only switched 
it to its current design for internal optimizer reasons).  

Making Bool conform to this would require manual conformance - if we were 
motivated to give Bool all the enum-like facilities (including a Bool.true and 
Bool.false member) then having it conform seems conceptually fine to me.

I would personally object to attempts to make optional conform though. One of 
its cases has an associated value and this isn’t something we should support 
IMO.  I believe that this is one of the roots of your objection.


swift-evolution mailing list

Reply via email to