> On Jan 11, 2018, at 9:26 PM, Gwendal Roué via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello, > >> Le 12 janv. 2018 à 02:36, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> The question I was weighing on it — what I thought Chris and Brent were >> discussing — was whether this new protocol should be used narrowly for cases >> of enums without associated types (which Chris favors), or whether it should >> find more broad use to mean “type which can enumerate all of its possible >> values” (which Brent finds interesting with caveats). This question has a >> bearing on whether the protocol’s name should be CaseEnumerable or >> ValueEnumerable. > > A classic mantra on this mailing list is that stdlib protocols ought to come > with generic use cases and algorithms.
While this is a good general goal, I don’t think this is an absolute requirement. As usual, I think the reality of the situation is more complicated: While we generally generally steer protocols towards being a “bag of semantics” instead of a “bag of syntax”, there are definitely exceptions to that rule, including the ExpressibleBy and other compiler intrinsic protocols which really are *all about* defining syntax. These protocols are not particularly useful for generic algorithms. The next level down are protocols like hashable/comparable that are useful for generic algorithms, but are also particularly interesting because of compiler synthesized conformances. They are unique because they are both sometimes interesting for generic algorithms, but also sometimes interesting just because you want the synthesized members on *concrete* types for non-generic uses. IMO, this is the bucket that this proposal falls into. Finally, there is the “normal” user defined protocol case, which are clearly about defining the semantics of types and nothing more. Duck typing and “defined by syntax” conformance is clearly out of bounds for these. -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
