> On Feb 17, 2017, at 11:50 AM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > Sorry, I couldn’t follow every thread. I simply couldn’t get that fact from > the given context of the first post by Anton. :) Just forget everything I > mentioned about typealias, because it was based on the assumption of an error > list. > > Anyways +1 for typed throws. The syntax throws(T) and rethrows(T) is fine by > me. > I feel like rethrows can and should be inferred. It’s just a pass-through.
> > > > -- > Adrian Zubarev > Sent with Airmail > > Am 17. Februar 2017 um 20:45:55, Matthew Johnson ([email protected] > <mailto:[email protected]>) schrieb: > >> >>> On Feb 17, 2017, at 1:42 PM, Adrian Zubarev via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> So the typed throws are going to be limited to a single error type, is that >>> the direction we're heading to? >> >> Yes, this topic was discussed thoroughly last year. >> >>> >>> -- >>> Adrian Zubarev >>> Sent with Airmail >>> >>> Am 17. Februar 2017 um 20:39:12, Anton Zhilin ([email protected] >>> <mailto:[email protected]>) schrieb: >>> >>>> In this case, you’d better create a new error type, which includes all the >>>> cases of those errors: >>>> >>>> // FileNotFoundError and WrongFormat are Error-s >>>> >>>> struct PreferencesError : Error { >>>> init(_: FileNotFoundError) >>>> init(_: WrongFormat) >>>> // ... >>>> } >>>> >>>> func readPreferences() throws(PreferencesError) >>>> In the most “lazy” case, you’d just create an enum of those two: >>>> >>>> enum PreferencesError : Error { >>>> case fileNotFound(FileNotFoundError) >>>> case wrongFormat(WrongFormatError) >>>> } >>>> Better yet, you should analyze, which cases are meaningful for user of >>>> readPreferences, and present them with appropriate interface. You may want >>>> to crash on those cases of initial error types, with which you can’t do >>>> anything on the level of abstraction of readPreferences. Some of the >>>> others will be merged or renamed. >>>> >>>> With proper error types, a single type in throws clause is enough, without >>>> sum types. >>>> >>>> 2017-02-17 22:22 GMT+03:00 Adrian Zubarev via swift-evolution >>>> <[email protected] <mailto:[email protected]>>: >>>> >>>> >>>> Sure thing, but that’s not what I was asking about. Kevin made a protocol >>>> that conforms to Error where all the his enums conformed to MyError >>>> protocol. That way we’re losing all enum cases and are not really a step >>>> further as before. >>>> >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <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
