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