I read:

Ma.allValues.count   // returns 8

But that sounds like all values will need to be computed in order to get
the count, so some people will be tempted to write:

Ma.lazy.allValues.count   // returns 8

To avoid that, it may be nicer to make enum `Ma` behaves like a collection
directly, so that we can write:

Ma.count   // returns 8
Ma.map { return "\($0)" }   // returns a stringification

A little bit like what was done on String when we dropped the requirement
of writing `.characters`, it would be perfect to directly drop the
requirement of writing `.allValues`.

Le mer. 10 janv. 2018 à 14:40, Chris Lattner via swift-evolution <
swift-evolution@swift.org> a écrit :

> 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.
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
swift-evolution mailing list

Reply via email to