[swift-evolution] Move placement of 'throws' statement

Russ Bishop xenadu at gmail.com
Thu Jan 12 01:30:00 CST 2017


> On Jan 11, 2017, at 10:35 AM, Erica Sadun <erica at ericasadun.com> wrote:
> 
>> 
>> On Jan 10, 2017, at 10:35 PM, Russ Bishop via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170111/0ea87075/attachment.html>


More information about the swift-evolution mailing list