I just realized that I didn't reply to that. This works with some caveats:
you need to maintain a manual mapping of error codes to integer values (good thing that I didn't actually have 300 cases between PermissionDenied and FluxCapacitorFailure); you now need an UnknownError to satisfy that IntegerLiteralConvertible's constructor is not failable (though in a real-world scenario you might need one anyway); you can't convert automatically between FileSystemError and MyLibError (leading to code less terse than it could). > Le 18 déc. 2015 à 13:42:39, T.J. Usiyan <[email protected]> a écrit : > > I think that you can accomplish this right now if you make your backing enum > literal convertible. String literal would have been the better choice in the > example below but I was feeling lazy. > > public enum MyLibError: ErrorType, IntegerLiteralConvertible { > case FileNotFound > case UnexpectedEOF > case PermissionDenied > // ... 300 cases later > case FluxCapacitorFailure > case SplineReticulationError > case UnknownError > > public init(integerLiteral value: Int) { > switch value { > case 0: > self = .FileNotFound > case 1: > self = .UnexpectedEOF > case 2: > self = .PermissionDenied > case 3: > self = .FluxCapacitorFailure > case 4: > self = .SplineReticulationError > default: > self = .UnknownError > } > } > } > > enum FileSystemError: MyLibError { > case FileNotFound = 0 > case UnexpectedEOF = 1 > case PermissionDenied = 2 > } > > On Fri, Dec 18, 2015 at 12:34 PM, Dennis Lysenko via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Sorry, I got a bit too excited and skimmed over the most important part of > the idea. So this is a special type of enum declaration in which you cannot > declare any new enum members. I personally have not seen a use for this in my > code but I would love to hear others' response to it. It is a very > interesting idea though. > > I'm going to go out on a limb with an idea that is in the same vein as this > one: What if we favored composition over inheritance here, and made it so > that you could transparently refer to members of other enums *without* having > another enum as a backing type? > > e.g., you have: > enum NetworkException { > case NoInternetError, SecurityError > } > > enum ParseException { > case FailedResponse(statusCode: Int) > case EmptyResponse > case MissingField(fieldName: String) > } > > As two general classes of errors. But for a full API call wrapper, you might > want an error class that composes the two, so that when calling the API call > from your UI code, you can display a "please check your connection" message > for NoInternetError, a "Please log in" error for FailedResponse with > statusCode=401, or a "server error" message for any of the rest. > > I wonder how do you and others feel about that use-case? I have certainly > seen it come up a lot in real-world projects that require resilient UI > interactions with nontrivial networking operations. > > Here are some quick code samples off the top of my head for how we might go > about this (let's say the API operation is "change profile picture": > > enum ChangePictureError { > include NetworkException > include ParseException > case PictureTooLarge > } > > or > > enum ChangePictureError { > compose NetworkException.NoInternetError > compose ParseException.EmptyResponse > compose ParseException.FailedResponse(statusCode: Int) > case PictureTooLarge > } > > Not a proposal by any stretch of the imagination, just a potential direction > inspired by your idea, Felix. > > > On Fri, Dec 18, 2015 at 12:21 PM Dennis Lysenko <[email protected] > <mailto:[email protected]>> wrote: > 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
