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