Thanks for the heads up! It wasn't just meant for you. Use of a generic Result type is one of my motivating cases.
1. If multiple libraries declare a generic type like that, converting between them becomes a pain. 2. Specific result types are useful and appropriate in many, if not most, cases. 3. protocols and retroactive conformance could make this less challenging On Sat, Oct 22, 2016 at 3:42 PM, David Sweeris <[email protected]> wrote: > Was not sending your reply only to me and not the list intentional? It’s > fine either way, I was just about to send this to the list when I realized > you’d only sent your reply to me, and I don’t want quote you somewhere if > you intentionally didn’t post there. > > On Oct 22, 2016, at 1:39 PM, T.J. Usiyan <[email protected]> wrote: > > I would actually hope otherwise. A real benefit of enums is compile time > guarantees. I am looking for a generic means to represent and handle a set > of possible outcomes. Not in the hopes of making everything fully generic > but lessening the redundant parts of dealing with, for example, Result > types. > > > I think you can do that now... > enum Result<Payload> { > case success(Payload) > case failure(Error) > } > > Then in your function… > func foo<T> (r: Result<T>) { > ... > switch r { > case .success(let p): ... > case .failure(let e): ... > } > ... > } > > Or am I just not understanding you? > > - Dave Sweeris >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
