<div dir="ltr">It certainly would complicate NSError bridging, David. What you could do is treat it as a special case, so saying "throws NSError" in Swift would not be allowed, but the objC functions that take an inout NSError parameter are automatically annotated by "throws NSError" in Swift usage. This steps around almost any restriction on what we programmers can specify to be thrown in Swift.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 18, 2015 at 12:35 PM David Owens II via swift-evolution <<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">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.<br>
<br>
FYI: I’ve added some updates to the criticism section to qualify the Java checked-exceptions and the multiple error type annotations.<br>
<br>
-David<br>
<br>
> On Dec 18, 2015, at 9:21 AM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>> wrote:<br>
><br>
> Oh, I see what you mean. I considered polymorphic types to be class hierarchies, when you're talking about ErrorType polymorphism.<br>
><br>
> 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.<br>
><br>
>> Le 18 déc. 2015 à 12:17:06, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :<br>
>><br>
>> 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?)<br>
>><br>
>>> Le 18 déc. 2015 à 11:58:44, David Owens II <<a href="mailto:david@owensd.io" target="_blank">david@owensd.io</a>> a écrit :<br>
>>><br>
>>><br>
>>>> On Dec 18, 2015, at 7:03 AM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>> wrote:<br>
>>>><br>
>>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> However, the only option today is polymorphic error types.<br>
>>><br>
>>> -David<br>
>>><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>
><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>