I agree, David's proposal looks good. Matthew concerned are interesting, and I think David answered them well.
Pierre > Le 23 déc. 2015 à 06:58, Thorsten Seitz via swift-evolution > <[email protected]> a écrit : > > David's proposal looks good enough for me. > > With regards to Matthew's worry of cluttering the code with conversion I'd > like to remark that this conversion code should only live on the border of > your API (the facade), so it should probably not be too invasive to your > business logic. > > -Thorsten > > > >> Am 22.12.2015 um 20:08 schrieb Matthew Johnson via swift-evolution >> <[email protected]>: >> >> >>>> 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]> >>>> 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 > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
