I thought there is already a pending proposal on typed throws? On Wed, Dec 28, 2016 at 22:34 thislooksfun via swift-evolution < [email protected]> wrote:
> +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]> 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 > > > _______________________________________________ > 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
