+1 for optional type definition. As someone also coming from Java, I agree that its implementation is less than ideal. When I first suggested moving the `throws` statement, I thought the decision on whether or not to declare (even optionally) the exception types had already been made. I see now that I was mistaken.
It seems clear that the two issues are closely tied, and the decision on moving the `throws` statement can't be made until a decision on type defined errors is made. For that reason, perhaps this should now move to a new thread discussing how best to implement a(n optional) typed `throws` system? -thislooksfun (tlf) > On Dec 28, 2016, at 3:59 PM, Christopher Kornher via swift-evolution > <[email protected]> wrote: > > -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] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > 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
