> On Dec 22, 2015, at 9:50 AM, Matthew Johnson <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
