<div dir="ltr">It certainly would complicate NSError bridging, David. What you could do is treat it as a special case, so saying &quot;throws NSError&quot; in Swift would not be allowed, but the objC functions that take an inout NSError parameter are automatically annotated by &quot;throws NSError&quot; 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 &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; 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>
&gt; On Dec 18, 2015, at 9:21 AM, Félix Cloutier &lt;<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>&gt; wrote:<br>
&gt;<br>
&gt; Oh, I see what you mean. I considered polymorphic types to be class hierarchies, when you&#39;re talking about ErrorType polymorphism.<br>
&gt;<br>
&gt; 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>
&gt;<br>
&gt;&gt; Le 18 déc. 2015 à 12:17:06, Félix Cloutier via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; a écrit :<br>
&gt;&gt;<br>
&gt;&gt; I&#39;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&#39;t that an issue? (Also, why is it the only option today?)<br>
&gt;&gt;<br>
&gt;&gt;&gt; Le 18 déc. 2015 à 11:58:44, David Owens II &lt;<a href="mailto:david@owensd.io" target="_blank">david@owensd.io</a>&gt; a écrit :<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Dec 18, 2015, at 7:03 AM, Félix Cloutier &lt;<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; For this reason, I don&#39;t like to encourage throwing polymorphic types, and I think that it&#39;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&#39;s currently possible but awkward to use polymorphic types as errors is exactly as much support as the feature should receive.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; However, the only option today is polymorphic error types.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -David<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<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>