I’d be ok with having enum/struct only error types, however, I don’t have a compelling reason to really limit their usage context. Also, that would complicate the bridging with NSError at the moment.
FYI: I’ve added some updates to the criticism section to qualify the Java checked-exceptions and the multiple error type annotations. -David > On Dec 18, 2015, at 9:21 AM, Félix Cloutier <[email protected]> wrote: > > Oh, I see what you mean. I considered polymorphic types to be class > hierarchies, when you're talking about ErrorType polymorphism. > > Yes, I think that the compiler should be aware of what the function can > throw, but I would be happier if it stayed a bit inconvenient to use > reference types. > >> Le 18 déc. 2015 à 12:17:06, Félix Cloutier via swift-evolution >> <[email protected]> a écrit : >> >> I'm not sure I understand your comment either. If I understand correctly, >> you say that the problem I describe is applicable only to polymorphic types >> (which is true). However, you then say that the only option today is >> polymorphic error types. Isn't that an issue? (Also, why is it the only >> option today?) >> >>> Le 18 déc. 2015 à 11:58:44, David Owens II <[email protected]> a écrit : >>> >>> >>>> On Dec 18, 2015, at 7:03 AM, Félix Cloutier <[email protected]> wrote: >>>> >>>> For this reason, I don't like to encourage throwing polymorphic types, and >>>> I think that it's a misconception to pretend that having a single type in >>>> the throws annotation ensures that the function throws a single type. In >>>> my opinion, the fact that it's currently possible but awkward to use >>>> polymorphic types as errors is exactly as much support as the feature >>>> should receive. >>> >>> I don’t follow this. Declaring a type that is an enum or a struct >>> absolutely guarantees that the function only returns a single type. If the >>> type is a class-based error, then sure, there’s not guarantee. >>> >>> However, the only option today is polymorphic error types. >>> >>> -David >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
