Sent from my iPad
> On Aug 17, 2017, at 11:58 PM, Chris Lattner <clatt...@nondot.org> 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 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. To be clear, I don't think anyone is arguing that we should remove the ability to simply mark a function `throws` with an implicit error type of `Error`! :) This is obviously crucial and would continue to be used in many cases. One important variation of this use case is that with typed errors it is also possible to refine `Error` and throw a slightly more specific existential. Obviously Apple will continue to use untyped errors in most or all APIs regardless of what we do and unannotated `throws` will continue to be the shortest syntax. The topic of Java errors has already been beat to death on the list in the past. I find it unfortunate that the counter-examples (notably Rust) are not usually mentioned. I haven't worked in Java, but my study of this topic in the past has convinced me the Java design has some serious flaws that are completely avoidable. 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* using typed errors via `Result<Value, ErrorType: Error>`. We don't have to speculate about how this feature might be used and what kind of benefits might be realized. We can have a discussion about what people are already doing and determine whether this model should be supported in the async / await world or not. What do you think of putting a call out to the broader Swift community to bring us concrete examples of how they are benefiting from using typed errors in async code. If we decide it should be, typed errors for synchronous code naturally follows. If we decide it shouldn't we have to be prepared for some noise about the unfortunate tradeoff developers will face between using async / await or continuing (pun not intended) to use explicit continuations and typed errors. I suspect most people would move to async / await and live with untyped errors (we don't see a lot of synchronous functions that return Result) but I also suspect there would be a lot of grumbling for a while. > > 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
