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

David Owens II david at owensd.io
Tue Dec 22 12:09:50 CST 2015


> On Dec 22, 2015, at 9:50 AM, Matthew Johnson <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. 

> 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.

> 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. 

-David

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


More information about the swift-evolution mailing list