> On Jan 11, 2017, at 10:35 AM, Erica Sadun <[email protected]> wrote:
>
>>
>> On Jan 10, 2017, at 10:35 PM, Russ Bishop via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> I thought there is already a pending proposal on typed throws?
>>>
>>> There was, I vaguely recall that it was by Russ? I don’t see any open PRs
>>> for it.
>>
>> Hey now, there is no need for name calling ;)
>>
>>
>>>
>>> I’m personally a big fan of typed throws, but I know that John McCall has
>>> strong concerns. I can’t argue that typed throws is a high priority at the
>>> moment, but as soon as we start talking about concurrency the topic of a
>>> Result type will come back up (for use with futures/async).
>>
>> I fall firmly in John McCall’s camp on this one. If someone wants to read
>> that part of the thread:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html
>>
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html>
>>
>> Of course if we want to automatically convert a throws function into an
>> awaitable Result then that naturally begs the question of either Result’s
>> error is typed as Error or not. I think I fall into the “as Error” camp here
>> too because Swift’s switch is powerful enough to pattern match on the type
>> fairly nicely but I haven’t thought about it very much.
>>
>>
>> All that said… if Swift got a macro system Rust’s error-chain seems to have
>> some interesting ideas that avoid a lot of boilerplate.
>
> If Swift has a canonical built-in system for reporting an Error, why wouldn't
> it be used here? Why use casting?
>
> — E
I was using shorthand for “struct Result<T> { let error: Error? }” vs “struct
Result<T, E: Error> { let error: E? }”… as in I prefer not having a second
generic type parameter to denote the error.
Russ
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
