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

[Jeremy Pereira]

> On 4 Jan 2017, at 20:39, thislooksfun <thislooksfun at repbot.org> wrote:
> 
> I still personally prefer the `throwing` prefix, but the way it currently is also works just fine, I'll just have to adjust.

Yes, if error throwing had come up on Swift Evolution before it was implemented, I would have been in that camp too, mainly because of my Objective-C and Java background - it would have seemed “logical" to me to put the “denotes can throw” keyword at the opposite end of the declaration to the return type. However, I am now used to the way it is and I think it works fine.


> 
> -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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>