protocol MyError: Error {}
enum MyFooError: MyError { … }
enum MyBarError: MyError { … }
func baz() throws(MyError)
> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I suggest we need to find a way to shorten the list of the possible error
> types with a the help of typeallias
>
> extension MyError1: Error { ... }
> extension MyError2: Error { ... }
> extension MyError3: Error { ... }
>
> typealias MyErrors = MyError1 | MyError2 | MyError3
>
> func foo() throws(MyErrors) -> MyResult
> func bar<T : Error>(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Februar 2017 um 19:47:47, Anton Zhilin via swift-evolution
> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:
>
>> Now this is on-topic, I guess.
>> Last time we stopped at John McCall’s syntax:
>>
>> extension MyError: Error { ... }
>>
>> func foo() throws(MyError) -> MyResult
>> It’s conservative and prevents visual ambiguity with extra parentheses.
>>
>> If we (somewhat) agree on this, then submitting a proposal will be trivial.
>>
>> _______________________________________________
>> 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
