Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

2017-02-23 21:01 GMT+03:00 Matthew Johnson : > > I don’t understand what you mean here. > I was a bit confused. Thanks to your clarification, I discovered that `rethrows` functions currently can use `throw` expression, but only in `catch` scope, which handles error

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

When I started changing the proposal, I noticed that examples with throws(E) look uglier than with rethrows, because of required constraint of E: Error. So I’d like to also discuss removal of Error constraint and its consequences. Some people talked about Objective-C interop. What are those

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

It’s funny, I literally just came across this. Turns out this is what the Dispatch overlay uses for dispatch_sync/DispatchQueue.sync. Here’s an even shorter example: func throwsUnexpected(one: ()throws->Void, hack: (Error)throws->Void) rethrows { try hack(SomeUnexpectedError.boo) } func

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

Thank you for replies, Matthew. They were very helpful to understand the proposed solution. On 23.02.2017 21:04, Matthew Johnson wrote: On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: I'm really sorry to interrupt your discussion, but could someone describe(or point to

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 1:03 PM, Vladimir.S wrote: > > On 23.02.2017 21:04, Matthew Johnson wrote: >> >>> On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: >>> >>> I'm really sorry to interrupt your discussion, but could someone >>> describe(or point to some

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 3:31 PM, Vladimir.S wrote: > > Thank you for replies, Matthew. They were very helpful to understand the > proposed solution. You’re welcome. Happy to help! > > On 23.02.2017 21:04, Matthew Johnson wrote: >> >>> On Feb 23, 2017, at 11:53 AM,

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 24, 2017, at 12:06 PM, David Hart wrote: > > Sending to mailing list: > > On 23 Feb 2017, at 01:37, Matthew Johnson via swift-evolution > > wrote: > >> # Analysis of the design of typed throws >> >> ##

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

Sending to mailing list: > On 23 Feb 2017, at 01:37, Matthew Johnson via swift-evolution > wrote: > > # Analysis of the design of typed throws > > ## Problem > > There is a problem with how the proposal specifies `rethrows` for functions > that take more than one

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 12:30 PM, Anton Zhilin wrote: > > 2017-02-23 21:01 GMT+03:00 Matthew Johnson >: > I don’t understand what you mean here. > > I was a bit confused. Thanks to your clarification, I discovered

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 12:24 PM, Karl Wagner wrote: > > It’s funny, I literally just came across this. Turns out this is what the > Dispatch overlay uses for dispatch_sync/DispatchQueue.sync. > > Here’s an even shorter example: > > func throwsUnexpected(one:

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

On 23.02.2017 21:04, Matthew Johnson wrote: On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: I'm really sorry to interrupt your discussion, but could someone describe(or point to some article etc) in two words why we need added complexity of typed throws(in comparing to use

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

I put together some valid Swift 3 sample code in case anyone is having trouble understanding the discussion of rethrows. The behavior may not be immediately obvious. func ithrow() throws { throw E.e } func nothrow() {} func rethrower(f: () throws -> Void, g: () throws -> Void) rethrows {

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: > > I'm really sorry to interrupt your discussion, but could someone describe(or > point to some article etc) in two words why we need added complexity of typed > throws(in comparing to use documentation) Thrown errors

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 11:41 AM, Anton Zhilin wrote: > > 2017-02-23 20:09 GMT+03:00 Matthew Johnson >: > >> On Feb 23, 2017, at 10:58 AM, Anton Zhilin > >

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

I'm really sorry to interrupt your discussion, but could someone describe(or point to some article etc) in two words why we need added complexity of typed throws(in comparing to use documentation) and *if* the suggested solution will guarantee that some method can throw only explicitly defined

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

2017-02-23 20:09 GMT+03:00 Matthew Johnson : > > On Feb 23, 2017, at 10:58 AM, Anton Zhilin wrote: > > See some inline response below. > Also, have you seen the issue I posted in Proposal thread? There is a way > to create an instance of "any"

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 10:58 AM, Anton Zhilin wrote: > > See some inline response below. > Also, have you seen the issue I posted in Proposal thread? There is a way to > create an instance of "any" type. Yes, I saw that. There is no problem with that at all. As I

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

See some inline response below. Also, have you seen the issue I posted in Proposal thread? There is a way to create an instance of "any" type. 2017-02-23 3:37 GMT+03:00 Matthew Johnson via swift-evolution < swift-evolution@swift.org>: > # Analysis of the design of typed throws > > ## Problem > >

[swift-evolution] [Discussion] Analysis of the design of typed throws

# Analysis of the design of typed throws ## Problem There is a problem with how the proposal specifies `rethrows` for functions that take more than one throwing function. The proposal says that the rethrown type must be a common supertype of the type thrown by all of the functions it