No, because an enum on top of an enum can only restrict the enumerants, not add new ones. An exception hierarchy increases the number of possibilities; an enum-backed enum decreases the number of possibilities.
> Le 18 déc. 2015 à 12:21:47, Dennis Lysenko <dennis.s.lyse...@gmail.com> a > écrit : > > Felix, > > This seems to be very interestingly tied into your comments about > polymorphism in 'throws' type annotations. Would you not feel that allowing > enums to be built on top of other enums would promote the kind of egregious > proliferation of exception polymorphism that discourages so many from > following Java's checked exception model? > > On Fri, Dec 18, 2015 at 11:29 AM Félix Cloutier <swift-evolution@swift.org > <mailto:swift-evolution@swift.org>> wrote: > Hi all, > > Swift currently has more or less three conceptual types of enums: > discriminated unions, lists of unique tokens, and lists of value of a raw > type. > > > // Discriminated unions > > enum Foo { > > case Bar(Int) > > case Baz(String) > > } > > > > // Lists of unique tokens (mixable with discriminated unions) > > enum Foo { > > case Frob > > case Nicate > > } > > > > // Lists of raw values > > enum Foo: String { > > case Bar = "Bar" > > case Baz = "Baz" > > } > > I think that the last case could be made more interesting if you could use > more types as underlying types. For instance, it could probably be extended > to support another enum as the backing type. One possible use case would be > to have a big fat enum for all the possible errors that your program/library > can throw, but refine that list into a shorter enum for functions that don't > need it all. > > > enum MyLibError: ErrorType { > > case FileNotFound > > case UnexpectedEOF > > case PermissionDenied > > // ... 300 cases later > > case FluxCapacitorFailure > > case SplineReticulationError > > } > > > > enum FileSystemError: MyLibError { > > case FileNotFound = .FileNotFound > > case UnexpectedEOF = .UnexpectedEOF > > case PermissionDenied = .PermissionDenied > > } > > This example could be made simpler if the `= .Foo` part was inferred from the > name, but you get the idea. > > In this case, it would be helpful (but not required) that FileSystemError was > convertible into a MyLibError, so that it could be transparently rethrown in > a function that uses the larger enum. I personally don't see why enums with a > specified underlying type can't be implicitly converted to it, but this is > not currently the case and it probably deserves some discussion as well. > > Is there any interest in that? > > Félix > > _______________________________________________ > 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
