[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Antoine Cœur]

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 at swift.org> a écrit :

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/1e7a9585/attachment-0001.html>