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 ;)
Cheers, Sent from my iPad > On 24 Dec 2015, at 14:26, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > >> On Dec 24, 2015, at 3:24 AM, Alejandro Martinez <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. > > > 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/ >> 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> 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>: >>>> >>>> >>>>>> On Dec 22, 2015, at 12:09 PM, David Owens II <da...@owensd.io> wrote: >>>>>> >>>>>> >>>>>> On Dec 22, 2015, at 9:50 AM, Matthew Johnson <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 >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
