<div dir="ltr">Felix, <div><br></div><div>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? </div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 18, 2015 at 11:29 AM Félix Cloutier <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
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.<br>
<br>
> // Discriminated unions<br>
> enum Foo {<br>
> case Bar(Int)<br>
> case Baz(String)<br>
> }<br>
><br>
> // Lists of unique tokens (mixable with discriminated unions)<br>
> enum Foo {<br>
> case Frob<br>
> case Nicate<br>
> }<br>
><br>
> // Lists of raw values<br>
> enum Foo: String {<br>
> case Bar = "Bar"<br>
> case Baz = "Baz"<br>
> }<br>
<br>
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.<br>
<br>
> enum MyLibError: ErrorType {<br>
> case FileNotFound<br>
> case UnexpectedEOF<br>
> case PermissionDenied<br>
> // ... 300 cases later<br>
> case FluxCapacitorFailure<br>
> case SplineReticulationError<br>
> }<br>
><br>
> enum FileSystemError: MyLibError {<br>
> case FileNotFound = .FileNotFound<br>
> case UnexpectedEOF = .UnexpectedEOF<br>
> case PermissionDenied = .PermissionDenied<br>
> }<br>
<br>
This example could be made simpler if the `= .Foo` part was inferred from the name, but you get the idea.<br>
<br>
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.<br>
<br>
Is there any interest in that?<br>
<br>
Félix<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>