[swift-evolution] Proposal: Allow Type Annotations on Throws
David Owens II
david at owensd.io
Fri Dec 18 11:34:56 CST 2015
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.
> On Dec 18, 2015, at 9:21 AM, Félix Cloutier <felixcca at yahoo.ca> 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 <swift-evolution at swift.org> 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 <david at owensd.io> a écrit :
>>>> On Dec 18, 2015, at 7:03 AM, Félix Cloutier <felixcca at yahoo.ca> 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.
>> swift-evolution mailing list
>> swift-evolution at swift.org
More information about the swift-evolution