3 ms·
> No exceptions. This is a big shift. With such a rich type system (very Hindley-Milner .. even with "protocols" that feel like type classes?), there is no nee
by sriku 12y ago
> No exceptions.
This is a big shift. With such a rich type system (very Hindley-Milner .. even with "protocols" that feel like type classes?), there is no need for exceptions, for much the same reason that Haskell doesn't have exceptions in the core language, but only a monad. This would force error situations to be explicitly modeled in the types of objects returned by functions/methods. A good thing I think.
However, it does leave the hole of what if an ObjC framework you call on raises an exception? Can't handle it within Swift code? Another big omission in the manual is lack of mention of anything to do with concurrency, though "use GCD" is seen as the solution (Swift closures are compatible with ObjC blocks).
- tomp 12y agoI disagree. I use exceptions a lot in OCaml. For example, when implementing a recursive type-checker, you really want to be able to abort (all the recursive invocations) quickly if e.g. you find an undeclared variable or a type error. Using an ADT would IMO incur an unacceptable syntactic and cognitive overhead.
- Chattered 12y agoOcaml exceptions are a misnomer, since they are often used as a control flow primitive for non-exceptional circumstances. The point is that they are cheap. Contrast with Java, where you wouldn't want to use exceptions the way you use them in Ocaml, and would instead favour other non-local exit primitives such as "return", "break" and "continue." Haskell doesn't care about this stuff, because lazy evaluation gives you the same control-flow patterns, and the exception monad ends up operationally equivalent to checked exceptions, but now with possibly exception throwing values made first-class. I doubt the same can be said of Swift.