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

[Derrick Ho]

John McCall +1
I agree. The placement should remain the same.
On Tue, Jan 3, 2017 at 8:29 AM John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

> On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> on Wed Dec 28 2016, Chris Lattner <clattner-AT-apple.com
> <http://clattner-at-apple.com/>> wrote:
>
> On Dec 28, 2016, at 9:52 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>
> it would be ambiguous to move the ‘throws’ keyword to the end of the
> function type, because you'd get:
>
>
> let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
>
>
> I see.
>
> We *could* say that the "throws" keyword comes after the return type
> unless it's a function type, in which case it comes after the return
> type's parameter list
>
>      let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>
> I admit this is a horrible rule from a language designer's point of view
> but there's a chance it could end up being better for users.
>
>
> Indeed this is horrid for an ivory tower language designer, but the
> pragmatic among them often have to make concessions to the real world.
> That said, I think this would be worse for typical swift programmers
> as well: it introduces multiple ways to do things,
>
>
> Do you mean it introduces multiple ways to do the *same* thing?  I
> didn't think I was introducing any of those.  If you think I was, you
> probably misunderstood my suggestion (or I did!), FWIW.
>
>
> Chris's point is that we can't stop allowing "throws" where it currently
> is, and
> therefore any proposal which allows it in a new place creates two ways of
> spelling the same thing.
>
> Also, your proposal reinterprets the currently-valid syntax:
>   (_ a : Int) -> (_ b : Float) throws -> Double
> Currently this means a non-throwing function that returns a throwing
> function.
> Your proposal flips it around.
>
> Also, I would find this extremely surprising as a user.  A core aspect of
> the
> first function type is written *inside* the second?  With all respect,
> Dave,
> that is just bizarre. :)
>
> I'm sorry if people dislike the placement of "throws", but that ship has
> sailed,
> and any attempt to "fix" it at this point is just going to cause problems
> for
> negligible benefit.
>
> As I see it, the current syntax has one mild deficiency, called out
> previously
> in this thread: a reader has to recognize that "throws -> X" does not mean
> that the function throws an X, but instead that it either throws or
> returns an X.
> It's always nice when something is immediately obvious and doesn't have to
> be explicitly learned, and I appreciate and mourn that my design may have
> fallen short of that standard here. However, overall I still do think the
> syntax
> is much cleaner than the alternatives, especially as return types grow more
> complicated, and that this small rule is not at all difficult to master.
>
> For what it's worth, this visual ambiguity is precisely why I would insist
> that
> any typed-throws addition be spelled "throws(X)" instead of "throws X".
>
> John.
>
>
>
> which work inconsistently and surprisingly in some cases.
>
> Here is a different way of looking at this: The predictable case is
> the one we already have now (and we wouldn’t take it away).  Is your
> beef with the current syntax so great that you think it is worth
> adding complexity to the language to privilege some special cases?
>
>
> Not really, no.
>
> --
> -Dave
> _______________________________________________
> 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/20170103/dab76864/attachment.html>