Brent, thanks for the detailed response, one question about it: > On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > > But that's beside the point. What I think the "`allValues` should be allowed > to be infinite" suggestion misses is that one of `ValueEnumerable`'s > semantics is that it's not only theoretically *possible* to enumerate all the > values, but actually *reasonable* to do so. ... > Some types, of course, fall into a gray area. `Int8` is fairly reasonable, > but larger integer types get increasingly unreasonable until, by `Int64`, we > reach types that would take decades to enumerate. Where the line should be > drawn is a matter of opinion. (My opinion, to be clear, is that we shouldn't > conform any of them; if someone really wants to do it, they can add a > retroactive conformance.)
I’m not sure which way you’re arguing here, but that’s ok. :-) In my opinion, while I can see where you are coming from (that it could be “reasonable” to allow random types to be ValueEnumerable) I don’t see what the *utility* or *benefit* that would provide. If we went with a simpler design - one that named this CaseEnumerable and .allCases - we would be heavily biasing the design of the feature towards enum-like applications that do not have associated types. This is “the” problem to be solved in my opinion, and would lead to a more clear and consistently understood feature that doesn’t have the ambiguity and “gray areas” that you discuss above. Given this bias, it is clear that infinite sequences are not interesting. Of course it would certainly be *possible* for someone to conform a non-enum-like type to CaseEnumerable, but that would be an abuse of the feature, and not a "gray area”. Is there some specific *utility* and *benefit* from creeping this feature beyond “enumerating cases in enums that don’t have associated types”? Is that utility and benefit large enough to make it worthwhile to water down the semantics of this protocol by making it so abstract? -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
