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

[Jeremy Pereira]

> On 3 Jan 2017, at 16:29, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> 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.

I’m going to stand up for the way it is now. I do not think the design falls short or is deficient. Bearing in mind that “->” actually means “returns”, I honestly can’t see why anybody would think 

    func foo() throws -> Int

could possibly be a function that throws an Int, especially if they have any knowledge of how the throw mechanism works in Swift (or any other language, for that matter). 

If it had been decided to put throws at the end, we’d probably be having an argument now that 

    func foo() -> Int throws

appears to return an Int that throws, an argument with much more validity, as pointed out upthread, because 

    func foo() -> () -> Int throws

really is ambiguous.


> 
> 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