I disagree with that, it works if you only have a single function parameter type that throws an error, but if there are more than one inferring the type won’t be possible anymore: func foo(_: () throws(T) -> Void, _: () throws(S) -> Void) rethrows(S) (here, we’re assuming that T is handled inside foo).
-- Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 21:17:42, Kevin Nattinger ([email protected]) schrieb: 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]) schrieb: On Feb 17, 2017, at 1:42 PM, Adrian Zubarev via swift-evolution <[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]) 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]>: 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] 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
