Re: [swift-evolution] typed throws

on Fri Aug 25 2017, John McCall wrote: On Aug 25, 2017, at 12:18 PM, Dave Abrahams via swift-evolution wrote: on Fri Aug 18 2017, Joe Groff wrote: On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution

Re: [swift-evolution] typed throws

> On Aug 25, 2017, at 12:18 PM, Dave Abrahams via swift-evolution > wrote: > on Fri Aug 18 2017, Joe Groff wrote: > >>> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] typed throws

on Fri Aug 18 2017, Joe Groff wrote: >> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution >> wrote: >> >> Essentially, you give Error a tagged-pointer representation to allow >> payload-less errors on non-generic error types to

Re: [swift-evolution] typed throws

on Thu Aug 17 2017, John McCall wrote: >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson

Re: [swift-evolution] typed throws

> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution > wrote: > > The only practical merit of typed throws I have ever seen someone demonstrate > is that it would let them use contextual lookup in a throw or catch. Let me take this in a slightly

Re: [swift-evolution] typed throws

> On 18. Aug 2017, at 08:27, John McCall via swift-evolution > wrote: > >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew

Re: [swift-evolution] typed throws

Sent from my iPad > On Aug 19, 2017, at 2:16 PM, Xiaodi Wu wrote: > >> On Sat, Aug 19, 2017 at 2:04 PM, Matthew Johnson >> wrote: >> >> >> Sent from my iPad >> >>> On Aug 19, 2017, at 12:43 PM, Xiaodi Wu wrote: >>> >>>

Re: [swift-evolution] typed throws

On Sat, Aug 19, 2017 at 2:04 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Aug 19, 2017, at 12:43 PM, Xiaodi Wu wrote: > > > On Sat, Aug 19, 2017 at 08:29 Matthew Johnson > wrote: > >> >> >> Sent from my iPad >>

Re: [swift-evolution] typed throws

Sent from my iPad > On Aug 19, 2017, at 12:43 PM, Xiaodi Wu wrote: > > >> On Sat, Aug 19, 2017 at 08:29 Matthew Johnson wrote: >> >> >> Sent from my iPad >> >>> On Aug 18, 2017, at 9:19 PM, Xiaodi Wu wrote: >>> >>> >>>

Re: [swift-evolution] typed throws

On Sat, Aug 19, 2017 at 08:29 Matthew Johnson wrote: > > > Sent from my iPad > > On Aug 18, 2017, at 9:19 PM, Xiaodi Wu wrote: > > > > On Fri, Aug 18, 2017 at 8:11 PM, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >>

Re: [swift-evolution] typed throws

Sent from my iPad > On Aug 18, 2017, at 9:19 PM, Xiaodi Wu wrote: > > > >> On Fri, Aug 18, 2017 at 8:11 PM, Matthew Johnson >> wrote: >> >> >> Sent from my iPad >> >>> On Aug 18, 2017, at 6:56 PM, Xiaodi Wu wrote: >>>

Re: [swift-evolution] typed throws

> On Aug 19, 2017, at 12:25 AM, John McCall via swift-evolution > wrote: >> On Aug 18, 2017, at 11:43 PM, Mark Lilback > > wrote: >> >>> >>> On Aug 18, 2017, at 2:27 AM, John McCall via swift-evolution >>>

Re: [swift-evolution] typed throws

> Typed throws is something we need to settle one way or the other, and I agree > it would be nice to do that in the Swift 5 cycle. > > For the purposes of this sub-discussion, I think there are three kinds of > code to think about: > 1) large scale API like Cocoa which evolve (adding

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 11:43 PM, Mark Lilback wrote: > >> >> On Aug 18, 2017, at 2:27 AM, John McCall via swift-evolution >> wrote: >> >> Even for non-public code. The only practical merit of typed throws I have >> ever seen someone demonstrate

Re: [swift-evolution] typed throws

On Aug 17, 2017, at 11:27 PM, John McCall wrote: > Even for non-public code. The only practical merit of typed throws I have > ever seen someone demonstrate is that it would let them use contextual lookup > in a throw or catch. People always say "I'll be able to

Re: [swift-evolution] typed throws

> > On Aug 18, 2017, at 2:27 AM, John McCall via swift-evolution > wrote: > > Even for non-public code. The only practical merit of typed throws I have > ever seen someone demonstrate is that it would let them use contextual lookup > in a throw or catch. People

Re: [swift-evolution] typed throws

On Fri, Aug 18, 2017 at 8:11 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Aug 18, 2017, at 6:56 PM, Xiaodi Wu wrote: > > Joe Groff wrote: > > An alternative approach that embraces the open nature of errors could be > to represent domains

Re: [swift-evolution] typed throws

Sent from my iPad > On Aug 18, 2017, at 6:56 PM, Xiaodi Wu wrote: > > Joe Groff wrote: > > An alternative approach that embraces the open nature of errors could be to > represent domains as independent protocols, and extend the error types that > are relevant to that

Re: [swift-evolution] typed throws

Joe Groff wrote: An alternative approach that embraces the open nature of errors could be to represent domains as independent protocols, and extend the error types that are relevant to that domain to conform to the protocol. That way, you don't obscure the structure of the underlying error value

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 6:29 PM, Xiaodi Wu wrote: > > On Fri, Aug 18, 2017 at 6:19 PM, Matthew Johnson > wrote: > >> On Aug 18, 2017, at 6:15 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] typed throws

On Fri, Aug 18, 2017 at 6:19 PM, Matthew Johnson wrote: > > On Aug 18, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> Sent from my iPad >> >>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution > > wrote: > > > Sent from my iPad > > On Aug 18, 2017, at 1:27 AM, John McCall

Re: [swift-evolution] typed throws

On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Aug 18, 2017, at 1:27 AM, John McCall wrote: > > >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution < >

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 1:09 PM, John McCall wrote: > >> >> On Aug 18, 2017, at 10:19 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >> On Aug 18, 2017, at 1:27 AM, John McCall wrote: >> On Aug 18, 2017, at

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 11:09 AM, John McCall via swift-evolution > wrote: > >> I think you're right that wrapping errors is tightly related to an effective >> use of typed errors. You can do a reasonable job without language support >> (as has been discussed on the

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 4:40 AM, Gwendal Roué wrote: > Hello all, > > I'm also on the "side" of untyped errors, but I can imagine how other > developers may like a stricter error hierarchy. It surely fits some > situations. > > Enter Result and Result: > > Since

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 10:19 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Aug 18, 2017, at 1:27 AM, John McCall wrote: > >>> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >>> wrote: >>>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 7:38 AM, Matthew Johnson via swift-evolution > wrote: > > I would like to reiterate the point I made in the question that spawned this > thread: there are *many* Swift libraries for writing async code of various > sorts which are *already*

Re: [swift-evolution] typed throws

Wouldn’t switching from `async` to `async throws` be both a source and ABI break for libraries? If so, there is a library evolution argument to `async` also encompassing throws as a reasonable default. It's likely that the non-throwing-ness of many `async` operations is an artifact of the

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 12:05 PM, Joe Groff wrote: > > >> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution >> > wrote: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson >>

Re: [swift-evolution] typed throws

> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution > wrote: > >> On Aug 17, 2017, at 7:39 PM, Matthew Johnson > > wrote: >> One related topic that isn’t discussed is type errors. Many third party

Re: [swift-evolution] typed throws

> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution > wrote: > > Essentially, you give Error a tagged-pointer representation to allow > payload-less errors on non-generic error types to be allocated globally, and > then you can (1) tell people to not

Re: [swift-evolution] typed throws

Sent from my iPad On Aug 18, 2017, at 1:27 AM, John McCall wrote: >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson

Re: [swift-evolution] typed throws

Hi John, tl;dr I think throws should be optionally typed. Ie. `func someSyscall(...) throws(POSIXError) -> Int` should be just as legal as `func doSomeFancyCocoaOperation() throws -> Void`. > [...] >> Here is where I think things stand on it: >> - There is consensus that untyped throws is the

Re: [swift-evolution] typed throws

Sent from my iPad > On Aug 17, 2017, at 11:58 PM, Chris Lattner wrote: > > Splitting this off into its own thread: Thanks. I considered starting a thread but decided to ask about it first in case it was considered out of scope for Swift 5. > >> On Aug 17, 2017, at

Re: [swift-evolution] typed throws

> There's no reason we couldn't do some tooling work to expose emergent > information about what kinds of errors are thrown by the current > implementation of a function, and maybe even check that against the current > documentation. Certainly, it should be possible to document particularly >

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 10:22 AM, John McCall wrote: > >> On Aug 18, 2017, at 3:28 AM, Charlie Monroe > > wrote: >>> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution >>>

Re: [swift-evolution] typed throws

Hello all, I'm also on the "side" of untyped errors, but I can imagine how other developers may like a stricter error hierarchy. It surely fits some situations. Enter Result and Result: Since Swift "native" errors don't fit well with asynchronous APIs, various ways to encapsulate them

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 3:28 AM, Charlie Monroe wrote: >> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution >> wrote: >>> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >>> wrote: >>>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 3:24 AM, Tino Heth <2...@gmx.de> wrote: > > >> The only practical merit of typed throws I have ever seen someone >> demonstrate is that it would let them use contextual lookup in a throw or >> catch. People always say "I'll be able to exhaustively switch over my >>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution > wrote: > >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew

Re: [swift-evolution] typed throws

> The only practical merit of typed throws I have ever seen someone demonstrate > is that it would let them use contextual lookup in a throw or catch. People > always say "I'll be able to exhaustively switch over my errors", and then I > ask them to show me where they want to do that, and

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution > wrote: > Splitting this off into its own thread: > >> On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: >> One related topic that isn’t discussed is type errors. Many third

Re: [swift-evolution] typed throws

Splitting this off into its own thread: > On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: > One related topic that isn’t discussed is type errors. Many third party > libraries use a Result type with typed errors. Moving to an async / await > model without also