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

[thislooksfun]

As I originally mentioned, once you are familiar with the facts that A) `throws` takes no parameters, and B) that `->` is returns, then I agree that iit is perfectly clear.

My original (and still continuing, but getting better) confusion might make more sense after seeing the following translated into Java (which was my original language)

//Swift:
func getData() throws -> Int {
  ...
}

//Java:
int getData() throws NumberFormatException {
  ...
}

Once again, after you're used to the Swift way, it makes perfect sense (and I kind of like it better than Java), but the initial switch-over from any statically defined thrown type language can be somewhat confusing.

I still personally prefer the `throwing` prefix, but the way it currently is also works just fine, I'll just have to adjust.

-thislooksfun (tlf)

> On Jan 4, 2017, at 6:10 AM, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> 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
> 
> _______________________________________________
> 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/20170104/ea04d11a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170104/ea04d11a/attachment.sig>