[swift-evolution] Proposal: Allow Type Annotations on Throws

Félix Cloutier felixcca at yahoo.ca
Fri Dec 18 11:21:32 CST 2015


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. 
>> 
>> -David
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list