> On Sep 9, 2017, at 12:36 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > > > Sent from my iPad > > On Sep 9, 2017, at 11:42 AM, gs. <griotsp...@gmail.com > <mailto:griotsp...@gmail.com>> wrote: > >> How does fragility play into this? Does this only work for fragile (closed) >> and internal/private/fileprivate enums? > > That's a great question. I think it would have to have that limitation. > Using Jordan's terminology, by definition a nonexhaustive cannot provide a > complete list of all values.
The runtime “knows” (or could be made to know) all the cases at any given moment in time (ignoring runtime-loaded modules, should they ever be supported). This is actually a strong argument for the creation of this feature. It would be impossible for such a list to be maintained manually. Making the list available somehow at compile time would almost guarantee a source-breaking/ABI-breaking change in the future. This raises a question: would models want anything other than the complete list of cases at runtime? For example, the module containing the root enum may have a use for the cases just defined within that module. I propose that the feature be defined to include all cases at runtime and that discussions of partial lists of cases be deferred until a use is found for them. > >> >> TJ >> >> On Sep 9, 2017, at 15:23, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> >>> Sent from my iPad >>> >>> On Sep 9, 2017, at 7:33 AM, Brent Royal-Gordon <br...@architechies.com >>> <mailto:br...@architechies.com>> wrote: >>> >>>>> On Sep 8, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> Here, people just want an array of all cases. Give them an array of all >>>>> cases. When it's not possible (i.e., in the case of cases with associated >>>>> values), don't do it. >>>> >>>> >>>> I agree it should be Int-indexed; that seems to be what people want from >>>> this. >>>> >>>> I seem to recall that there is information about the available enum cases >>>> in the module metadata. If so, and if we're willing to lock that in as >>>> part of the ABI design, I think we should write—or at least allow for—a >>>> custom Int-indexed collection, because this may allow us to recurse into >>>> associated value types. If we aren't going to have suitable metadata, >>>> though, I agree we should just use an Array. There are pathological cases >>>> where instantiating a large Array might be burdensome, but sometimes you >>>> just have to ignore the pathological cases. >>>> >>>> (The "infinite recursion" problem with associated values is actually >>>> relatively easy to solve, by the way: Don't allow, or at least don't >>>> generate, `ValuesEnumerable` conformance on enums with `indirect` cases.) >>> >>> This is the direction I think makes the most sense in terms of how we >>> should approach synthesis. The open question in my mind is what the exact >>> requirement of the protocol should be. Should it exactly match what we >>> synthesize (`[Self]` or an associated `Collection where Iterator.Element == >>> Self, Index == Int`) or whether the protocol should have a more relaxed >>> requirement of `Sequence where Iterator.Element == Self` like Tony proposed. >>> >>>> >>>> -- >>>> Brent Royal-Gordon >>>> Architechies >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
