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

[John McCall]

> 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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/cea473f1/attachment.html>