I have a concern that the placement of the 'throws' keyword in the function declaration makes the it less pleasant to read. I think it's interrupting the flow, which otherwise reads nicely as 'maps this to that'. Below is the best alternative I can think of, although I'm not a compiler expert, so I'm not sure how much difficulty this would cause for the parser.
func doStuff(x:Int, y:Int) -> Int, throws {
...
}That wouldn't work. See this example:
func f() throws -> Int -> Int {
return { $0 }
}
func g() -> Int throws -> Int {
return { $0 }
}
let a = try f() // f() is a throwing function
let b = a(1) // the result of f() is a function that returns an int
let c = g() // g() is not a throwing function
let d = try c() // the result of g() is a throwing function that returns an intI might help to think of "throws" as marking what will be an implicit parameter to the function, like NSError in ObjC. However, unlike ObjC, Swift forces you to deal with that error parameter.
I like to think about it more as an implicit return value, like the Result enums people were discussing before 2.0 was announced. "throws" declares the function to either return the specified data type or an error, like it would return this enum:
enum ResultOrError<T> {
case Result(T)
case Error(ErrorType)
}I think the whole notion of `throws` as a suffix is very odd. It should be a prefix like everything else. We already commonly make declarations such as:
@objc private final func myFunc() {}
It would do no harm whatever to add `throws` to this list of prefixes:
@objc private final throws func myFunction()
There are examples in this very thread where a prefix would not work.