TLDR: I support moving throws, and also think that ‘typed throws’ should
fit for Phase 2, at least.

let x : (_ a : Int) -> (_ b: Float) throws -> Double throws

Count me in those who cried in anger :)
------------------------------

I see why current syntax is very logical for currying:

let x: (Int) throws -> (Float) throws -> Double   // clean

let x: (Int) -> (Float) -> Double throws throws   // looks ambiguous

Although, the ambiguity can be resolved using parentheses:

let x: (Int) -> ((Float) -> Double throws) throws

let x: (Int) -> ((Float) -> Double throws Error2) throws Error1   //
with 'typed throws'

Compare it to how we incorporate optionals (which are just another form of
error handling) in curried functions now:

let x: (Int) -> ((Float) -> Double?)?

Overall, current Swift syntax is uniquely nice to error handling in curried
functions. Is it worth keeping this advantage? Probably not, if the new
form does not contain too much noise and is even more logical. Everything
slides into place, if throws is a binary operator on types with precedence
higher than ->. Although A throws B is not a type on itself, I can clearly
see it becoming one in the future. Then try will handle pattern matching of
such types.

Another point for the suggested syntax: as we now know, Swift users prefer
to see results after -> in function declarations. Is it stretching too far
to conclude that error type is a possible result, and should also come
after ->?
​
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to