> On Feb 24, 2017, at 11:00 AM, Joe Groff via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>> On Feb 23, 2017, at 10:36 PM, Russ Bishop <xen...@gmail.com 
>> <mailto:xen...@gmail.com>> wrote:
>> 
>> 
>>> On Feb 21, 2017, at 8:18 AM, Joe Groff <jgr...@apple.com 
>>> <mailto:jgr...@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to