[swift-evolution] Move placement of 'throws' statement

[thislooksfun]

+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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161228/887d12b1/attachment.html>