> On Dec 24, 2015, at 7:51 PM, Alejandro Martinez <alexi...@gmail.com> wrote: > > Absolutely agree Matthew. > My point was that if this is the temporary tradeoff that we have to support > for me is worth it. Having typed throws looks like a great next step to > improving the current error system. > Curious to see your ideas about that ;) >
Agree with you on that. I think a proposal for proper error conversion during propagation could actually follow this one pretty quickly so we may not have to wait too long. I am hoping it is possible both could make it in the Swift 3 timeframe if both are accepted. > Cheers, > > Sent from my iPad > > On 24 Dec 2015, at 14:26, Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > >> >> >> Sent from my iPad >> >> On Dec 24, 2015, at 3:24 AM, Alejandro Martinez <alexi...@gmail.com >> <mailto:alexi...@gmail.com>> wrote: >> >>> Hi! >>> I've been following the conversation closely so here are my 2c >>> >>> TL;TR: +1 >>> >>> After proposing solutions for the concerns about conversions this is a >>> clear +1. Overloading the conversion functions is how it works in Rust and >>> I think is a good tradeoff, even without the magical "try!" That Rust has. >>> Maybe we could explore something like that when Swift give us a macro like >>> system. But for now I will be happy with this. >> >> Rust actually uses a trait (the Rust equivalent of a protocol) to do this. >> It isn't possible in Swift because protocols cannot have type parameters >> like traits can in Rust and there is no other mechanism in Swift with >> equivalent capability. >> >> This means that Rust's From mechanism is generic and is part of the standard >> library. It is part of the common vocabulary of Rust programmers. This is >> a significant advantage over a solution that uses ad-hoc overloading relying >> on a convention that is likely to vary between teams. Some teams probably >> won't even be aware of the possibility to adopt such a convention if it >> isn't part of our common vocabulary. >> >> Here is what the Rust documentation has to say about this: >> >>> From is very useful because it gives us a generic way to talk about >>> conversion from a particular type T to some other type (in this case, “some >>> other type” is the subject of the impl, or Self). The crux of From is the >>> set of implementations provided by the standard library >>> <https://doc.rust-lang.org/std/convert/trait.From.html>. >> >> >> Swift is not Rust and I personally believe a different approach to handling >> error translation during propagation would be more Swifty for a number of >> reasons. I believe that would be the case even if we had macros and >> protocols with type parameters. I am continuing to think about this and >> will probably submit a proposal if / when David's proposal is accepted. >> >> IMO it is very important that we have a standard mechanism for translating >> errors during propagation. >> >> >>> >>> The most important thing to remember is that this changes will not affect >>> people that prefers the untyped throws, as they can continue doing it like >>> now. I think this is really important as will allow us to ignore typed >>> errors when writing prototyping code, but it will give the option to >>> improve the safety of our code when is time for that. >>> >>> Thanks for the proposal and the interesting discussion. >>> >>> Sent from my iPad >>> >>> PS: i've been playing on porting the example from Rust errors page to >>> Swift. >>> http://alejandromp.com/blog/2015/12/23/rust-error-handling-swift-script/ >>> <http://alejandromp.com/blog/2015/12/23/rust-error-handling-swift-script/> >>> Will be interesting to try it again with the changes from this proposal ;) >>> >>> On 23 Dec 2015, at 05:58, Thorsten Seitz via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> 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 >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >>>> >>>>> >>>>>> On Dec 22, 2015, at 12:09 PM, David Owens II <da...@owensd.io >>>>>> <mailto:da...@owensd.io>> wrote: >>>>>> >>>>>> >>>>>>> On Dec 22, 2015, at 9:50 AM, Matthew Johnson <matt...@anandabits.com >>>>>>> <mailto:matt...@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 >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
