Throws, rethrows and declaration-modifiers in function declarations

[Matthieu_Oger]

Hello,

I'm currently reading the updated Swift 3 preview book, and was
wondering about the `throws` and `rethrows` keywords.

In a function declaration, all the keywords are at the beginning, except
for `throws` and `rethrows`, which are… oddly placed.

In the grammar:

*function-declaration *→ *function-head[1] ­function-name[2]­ **generic-parameter-clause[3]­*opt­*function-
signature[4]­ **function-body[5]­*opt­
*function-head *→ *attributes[6]­*opt­*declaration-
modifiers[7]­*opt­func­
*function-signature *→ *parameter-clause[8]­*throws­opt­*function-
result[9]­*opt­
*function-signature *→ *parameter-clause[10]­*rethrows­*function-
result[11]­*opt­

Is there a reason to have throws and rethrows at this specific position,
instead of declaration-modifiers?

ie.:

This:

func send() throws -> String {}

Becomes:

throwing func send() -> String {}
rethrowing func send() -> String {}

Like:

mutating func send() -> String {}

Or:

throw func send() -> String {}
rethrow func send() -> String {}

Like:

override func send() -> String {}

(You can also see the weird difference between `override` and
`mutating`, one using the -ing suffix, the other being infinitive)

Am I missing something? I find that these keywords break the flow of the
function declaration, separating the parameters and the return type,
which is never done anywhere else.

Thanks.

···

--
Matthieu Oger
Pixelnest Studio[12]

Links:

   1. Declarations — The Swift Programming Language (Swift 5.7)
   2. Declarations — The Swift Programming Language (Swift 5.7)
   3. Generic Parameters and Arguments — The Swift Programming Language (Swift 5.7)
   4. Declarations — The Swift Programming Language (Swift 5.7)
   5. Declarations — The Swift Programming Language (Swift 5.7)
   6. Attributes — The Swift Programming Language (Swift 5.7)
   7. Declarations — The Swift Programming Language (Swift 5.7)
   8. Declarations — The Swift Programming Language (Swift 5.7)
   9. Declarations — The Swift Programming Language (Swift 5.7)
  10. Declarations — The Swift Programming Language (Swift 5.7)
  11. Declarations — The Swift Programming Language (Swift 5.7)
  12. http://pixelnest.io/

[Lmpessoa (Leonardo Pessoa)]

I'm really really sure I don't want to see a `override throwing
mutating func foo()` anywhere. Too much to read and no commas (please,
I'm not saying this as a challenge!).

Additionally, I think `overriden` would make the code much more
english-readable and I'm still not proposing it.

L

···

On 19 July 2016 at 16:01, Javier Soto via swift-evolution <swift-evolution@swift.org> wrote:

I see where you're coming from.
Without any actual insight into the design of this syntax, I think throws is
in the position it is because it relates more to the return type of the
function. Aka a `throws -> T` function can either throw ErrorProtocol OR
return a T value.
On Tue, Jul 19, 2016 at 10:51 AM Matthieu Oger via swift-evolution > <swift-evolution@swift.org> wrote:

Hello,

I'm currently reading the updated Swift 3 preview book, and was wondering
about the `throws` and `rethrows` keywords.

In a function declaration, all the keywords are at the beginning, except
for `throws` and `rethrows`, which are… oddly placed.

In the grammar:

function-declaration → function-head ­function-name­
generic-parameter-clause­opt­function-signature­ function-body­opt­

function-head → attributes­opt­declaration-modifiers­opt­func­

function-signature → parameter-clause­throws­opt­function-result­opt­

function-signature → parameter-clause­rethrows­function-result­opt­

Is there a reason to have throws and rethrows at this specific position,
instead of declaration-modifiers?

ie.:

This:

func send() throws -> String {}

Becomes:

throwing func send() -> String {}
rethrowing func send() -> String {}

Like:

mutating func send() -> String {}

Or:

throw func send() -> String {}
rethrow func send() -> String {}

Like:

override func send() -> String {}

(You can also see the weird difference between `override` and `mutating`,
one using the -ing suffix, the other being infinitive)

Am I missing something? I find that these keywords break the flow of the
function declaration, separating the parameters and the return type, which
is never done anywhere else.

Thanks.

--
Matthieu Oger
Pixelnest Studio

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Javier Soto

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Javi (Javier Soto)]

I see where you're coming from.
Without any actual insight into the design of this syntax, I think throws
is in the position it is because it relates more to the return type of the
function. Aka a `throws -> T` function can either throw ErrorProtocol OR
return a T value.

···

On Tue, Jul 19, 2016 at 10:51 AM Matthieu Oger via swift-evolution < swift-evolution@swift.org> wrote:

Hello,

I'm currently reading the updated Swift 3 preview book, and was wondering
about the `throws` and `rethrows` keywords.

In a function declaration, all the keywords are at the beginning, except
for `throws` and `rethrows`, which are… oddly placed.

In the grammar:

*function-declaration *→ *function-head
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-head> ­function-name
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-name>­ **generic-parameter-clause
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/GenericParametersAndArguments.html#//apple_ref/swift/grammar/generic-parameter-clause>­*
opt­*function-signature
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-signature>­ **function-body
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-body>­*
opt­

*function-head *→ *attributes
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/swift/grammar/attributes>­*
opt­*declaration-modifiers
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/declaration-modifiers>­*
opt­func­

*function-signature *→ *parameter-clause
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/parameter-clause>­*
throws­opt­*function-result
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-result>­*
opt­

*function-signature *→ *parameter-clause
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/parameter-clause>­*
rethrows­*function-result
<https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-result>­*
opt­

Is there a reason to have throws and rethrows at this specific position,
instead of declaration-modifiers?

ie.:

This:

func send() throws -> String {}

Becomes:

throwing func send() -> String {}
rethrowing func send() -> String {}

Like:

mutating func send() -> String {}

Or:

throw func send() -> String {}
rethrow func send() -> String {}

Like:

override func send() -> String {}

(You can also see the weird difference between `override` and `mutating`,
one using the -ing suffix, the other being infinitive)

Am I missing something? I find that these keywords break the flow of the
function declaration, separating the parameters and the return type, which
is never done anywhere else.

Thanks.

--
Matthieu Oger
Pixelnest Studio <http://pixelnest.io/&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Javier Soto

[hartbit (David Hart)]

Because its part of the type. That’s why we can have throws on closure types:

func foo(bar: Int throws -> Void) {}

···

On 19 Jul 2016, at 19:51, Matthieu Oger via swift-evolution <swift-evolution@swift.org> wrote:

Hello,

I'm currently reading the updated Swift 3 preview book, and was wondering about the `throws` and `rethrows` keywords.

In a function declaration, all the keywords are at the beginning, except for `throws` and `rethrows`, which are… oddly placed.

In the grammar:

function-declaration → function-head <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-head> ­function-name <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-name>­ generic-parameter-clause <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/GenericParametersAndArguments.html#//apple_ref/swift/grammar/generic-parameter-clause>­opt­function-signature <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-signature>­ function-body <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-body>­opt­
function-head → attributes <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/swift/grammar/attributes>­opt­declaration-modifiers <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/declaration-modifiers>­opt­func­
function-signature → parameter-clause <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/parameter-clause>­throws­opt­function-result <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-result>­opt­
function-signature → parameter-clause <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/parameter-clause>­rethrows­function-result <https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/swift/grammar/function-result>­opt­

Is there a reason to have throws and rethrows at this specific position, instead of declaration-modifiers?

ie.:

This:

func send() throws -> String {}

Becomes:

throwing func send() -> String {}
rethrowing func send() -> String {}

Like:

mutating func send() -> String {}

Or:

throw func send() -> String {}
rethrow func send() -> String {}

Like:

override func send() -> String {}

(You can also see the weird difference between `override` and `mutating`, one using the -ing suffix, the other being infinitive)

Am I missing something? I find that these keywords break the flow of the function declaration, separating the parameters and the return type, which is never done anywhere else.

Thanks.

--
Matthieu Oger
Pixelnest Studio <http://pixelnest.io/&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution