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

[Dennis Lysenko]

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.

On Fri, Dec 18, 2015 at 12:35 PM David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:

> 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 <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.
> >>>
> >>> -David
> >>>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/c4fb9e41/attachment.html>