on Thu Aug 17 2017, John McCall <swift-evolution@swift.org> wrote: >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> 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. > > 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 exhaustively switch over my errors", and then I ask them to > show me where they want to do that, and they show me something that > just logs the error, which of course does not require typed throws. > Every. Single. Time. > > Sometimes we then go on to have a conversation about wrapping errors > in other error types, and that can be interesting, but now we're > talking about adding a big, messy feature just to get "safety" > guarantees for a fairly minor need. > > Programmers often have an instinct to obsess over error taxonomies > that is very rarely directed at solving any real problem; it is just > self-imposed busy-work.
+1; I couldn't have said this any better. The problem is not merely that by implementing this we'd be expending effort and adding language complexity; it's also that programmers love to classify things and those working with statically-typed languages have a natural inclination to think “more static type information is better,” so they *will* use this feature whether it's good for code or not. -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution