Splitting this off into its own thread: > On Aug 17, 2017, at 7:39 PM, Matthew Johnson <matt...@anandabits.com> 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 introducing typed errors into Swift would require giving > up something that is highly valued by many Swift developers. Maybe Swift 5 > is the right time to tackle typed errors as well. I would be happy to help > with design and drafting a proposal but would need collaborators on the > implementation side.
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 significant functionality) over the course of many years and can’t break clients. 2) the public API of shared swiftpm packages, whose lifecycle may rise and fall - being obsoleted and replaced by better packages if they encounter a design problem. 3) internal APIs and applications, which are easy to change because the implementations and clients of the APIs are owned by the same people. These each have different sorts of concerns, and we hope that something can start out as #3 but work its way up the stack gracefully. Here is where I think things stand on it: - There is consensus that untyped throws is the right thing for a large scale API like Cocoa. NSError is effectively proven here. Even if typed throws is introduced, Apple is unlikely to adopt it in their APIs for this reason. - There is consensus that untyped throws is the right default for people to reach for for public package (#2). - There is consensus that Java and other systems that encourage lists of throws error types lead to problematic APIs for a variety of reasons. - There is disagreement about whether internal APIs (#3) should use it. It seems perfect to be able to write exhaustive catches in this situation, since everything in knowable. OTOH, this could encourage abuse of error handling in cases where you really should return an enum instead of using throws. - Some people are concerned that introducing typed throws would cause people to reach for it instead of using untyped throws for public package APIs. - Some people think that while it might be useful in some narrow cases, the utility isn’t high enough to justify making the language more complex (complexity that would intrude on the APIs of result types, futures, etc) I’m sure there are other points in the discussion that I’m forgetting. One thing that I’m personally very concerned about is in the systems programming domain. Systems code is sort of the classic example of code that is low-level enough and finely specified enough that there are lots of knowable things, including the failure modes. Beyond expressivity though, our current model involves boxing thrown values into an Error existential, something that forces an implicit memory allocation when the value is large. Unless this is fixed, I’m very concerned that we’ll end up with a situation where certain kinds of systems code (i.e., that which cares about real time guarantees) will not be able to use error handling at all. JohnMC has some ideas on how to change code generation for ‘throws’ to avoid this problem, but I don’t understand his ideas enough to know if they are practical and likely to happen or not. -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
