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

[Matthew Johnson]

> On Dec 22, 2015, at 12:09 PM, David Owens II <david at owensd.io> wrote:
> 
> 
>> On Dec 22, 2015, at 9:50 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> Unfortunately, I don’t see a way to make it safe.  You had to use fatalError in a default case to make it work.  An alternative would have been to include an ‘UnknownError’ case in ‘PublishedError’.  Neither is not an acceptable solution IMO.
> 
> I need the fatalError() because the sample is a working example in Swift today. If we had typed errors, this would simply work:
> 
>    static func from<T>(@autoclosure fn: () throws InternalError -> T) throws PublishedError -> T {
>         do {
>             return try fn()
>         }
>         catch InternalError.Internal(let value) {
>             throw PublishedError.Converted(value: value)
>         }
>     }
> 
> This states that the only closure accepted is one that throws an InternalError. 

Ok, so you suggest writing a specific overload for each combination of error types that are convertible.  Got it.  Not sure why I didn’t think of overloads.  I was too focused on a general try function dispatching to an initializer.

That is indeed safe and I can live with it.  Thanks for taking the time to work through these examples with me and help to identify patterns that address my concerns!

I still find it unfortunate that this is in the realm of a pattern though.  IMO it would be much better if it was part of the common Swift vocabulary, either as a language feature or a library function but that isn’t possible as a generic implementation isn’t possible.

> 
>> This top level `from` example also brings up a couple of points that I don’t recall being addressed in your proposal.  Specifically, the interaction of typed errors with generics and type inferrence.
> 
> I call out in the proposal that errors work with generics no differently than other types.

Great, I must have missed that.

> 
>> I still consider this to be an unresolved concern.  I would like to have a safe way to perform error conversion during propagation without cluttering up my control flow and seriously degrading readability.  This is a problem that can and has been solved in other languages.  IMO it is should be considered an essential element of a proposal introducing typed errors.
> 
> When Swift has a macro as powerful as Rust, then this is a solved problem as well. However, Swift isn’t there yet. 

I would prefer a solution to this that didn’t require macros which would fit better in Swift.  This feature is buried in the `try!` macro in Rust as Rust doesn’t have built-in language level error handling support.  

Swift already has `try` built into the language.  IMO it would be better to have it handled by the built-in language level error handling support in Swift.  That seems like the more “Swifty” approach.  We could have a Swift macro `tryAndConvert` or something, but that seems inelegant.

We’ve gone back and forth on this quite a bit but nobody else has chimed in.  I’m curious to hear what others thing.  I would love it if any lurkers would jump in and comment!

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/9719bcd2/attachment.html>