[swift-evolution] [Pitch] Typed throws

[Matthew Johnson]

> On Feb 24, 2017, at 11:00 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 23, 2017, at 10:36 PM, Russ Bishop <xenadu at gmail.com <mailto:xenadu at gmail.com>> wrote:
>> 
>> 
>>> On Feb 21, 2017, at 8:18 AM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>>>> 
>>>> 
>>>> Yeah but Rust has a macro system so error-chain makes re-wrapping trivial. A simple `chain_err(|| “my new error message”)` is enough to define and “throw” a new error that wraps the underlying error.
>>> 
>>> That was my point—they recognized error chaining/layering as a common phonemenon and provided affordances for it as part of their design. I was saying we should do the same if we investigate typed errors seriously. (Not sure why you mentioned macros—chain_err is just a regular method, and could be defined as an extension method on Error in swift today.)
>>> 
>>> -Joe
>> 
>> Sorry, I meant error_chain! handles the boilerplate. At the end of the day something has to create the new error types.
>> 
>> I agree with you on the chaining; if we really do want to go down this road we need an elegant solution. Seeing people talk about getting rid of rethrows makes me think this isn’t yet a serious discussion.

Is it just the syntactic sugar you would miss or is there more to it?  Did you see the analysis I sent out showing a case rethrows can’t handle and a problem the current proposal has in handling typed rethrows?

> 
> If `rethrows` can be turned into sugar for regular type parametricity, I think that'd be a win over our current model. The sugar is probably still useful since `<E> (() throws E -> ()) throws SomethingDerivedFrom<E> -> ()` is common enough; whether SomethingDerivedFrom<E> is E, Error, or MyModulesErrorWrapper<E> would have to be discussed.

I don’t mind keeping rethrows as syntactic sugar but I would like to have a solution that can handle all cases including the one it isn’t able to handle.

I almost included something like this in the analysis I sent out.  I thought maybe injecting implicit generic parameters would be a little bit too magical.  It would be super convenient though!



> 
> -Joe
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170224/29be913e/attachment.html>