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

[Xiaodi Wu]

I thought there is already a pending proposal on typed throws?
On Wed, Dec 28, 2016 at 22:34 thislooksfun via swift-evolution <
swift-evolution at swift.org> 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 <
> 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> 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
> 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
>
>
> _______________________________________________
> 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/20161229/19f4cc17/attachment.html>