-1 for addressing this now. Typed throws will undoubtedly affect this change and the two issues should be addressed at the same time.
As a Java veteran, I agree with the sentiment to avoid the Java exception typing mechanism which complicates using and maintaining large projects. Knowing the recoverable exceptions that a function can throw cane be useful, however, and some sort of optional listing of exception types is probably the best solution. > On Dec 28, 2016, at 2:36 PM, Anton Zhilin via swift-evolution > <[email protected]> wrote: > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
