[Proposal draft #2] Naming Functions with Argument Labels


(Douglas Gregor) #1

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
Author(s): Doug Gregor <https://github.com/DougGregor>
Status: Awaiting Review
Review manager: TBD
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>Introduction

Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, when specifying the name of a function, one can only provide the base name, (e.g., insertSubview) without the argument labels. For overloaded functions, this means that one must disambiguate based on type information, which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program---one cannot provide the argument labels when naming a function, nor are property and subscript getters and setters referenceable. This proposal introduces a general syntax that allows one to name anything that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>. It included support for naming getters/setters (separately brought up by Michael Henson here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>, continued here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>). Joe Groff convinced <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me that lenses are a better approach for working with getters/setters, so I've dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>Motivation

It's fairly common in Swift for multiple functions or methods to have the same "base name", but be distinguished by parameter labels. For example, UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}
which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to ask for the Objective-C selector for a given method (rather than writing a string literal). The argument to such an operation would likely be a reference to a method, which would benefit from being able to name any method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed solution

I propose to extend function naming to allow compound Swift names (e.g., insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)
let fn1 = someView.insertSubview(_:aboveSubview:)
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)
The "produce the Objective-C selector for the given method" operation will be the subject of a separate proposal. However, here is one possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed Design

Grammatically, the primary-expression grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]
to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
Within the parentheses, the use of "+" is important, because it disambiguates:

f()
as a call to f rather than a reference to an f with no arguments. Zero-argument function references will still require disambiguation via contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives considered

Joe Groff notes <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> that lenses are a better solution than manually retrieving getter/setter functions when the intent is to actually operate on the properties.

Bartlomiej Cichosz suggests <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a general partial application syntax using _ as a placeholder, e.g.,

aGameView.insertSubview(_, aboveSubview: playingSurfaceView)
When all arguments are _, this provides the ability to name any method:

aGameView.insertSubview(_, aboveSubview: _)
I decided not to go with this because I don't believe we need such a general partial application syntax in Swift. Closures using the $ names are nearly as concise, and eliminate any questions about how the _ placeholder maps to an argument of the partially-applied function:

{ aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

  - Doug


(Joe Groff) #2

SGTM. A few points I didn't see addressed from the last thread:

- Do we need the '_' representing unlabeled arguments? 'foo(:bar:)' should be workable, as in ObjC.
- How do references to defaulted or variadic arguments work? Do you have to reference their labels completely in declared order, or could you refer to 'func foo(x: Int = 5, y: String = "")' as 'foo(y:x:)', 'foo(x:)', and/or 'foo(y:)' as well?

-Joe

···

On Jan 11, 2016, at 11:03 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
Author(s): Doug Gregor <https://github.com/DougGregor>
Status: Awaiting Review
Review manager: TBD
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>Introduction

Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, when specifying the name of a function, one can only provide the base name, (e.g., insertSubview) without the argument labels. For overloaded functions, this means that one must disambiguate based on type information, which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program---one cannot provide the argument labels when naming a function, nor are property and subscript getters and setters referenceable. This proposal introduces a general syntax that allows one to name anything that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>. It included support for naming getters/setters (separately brought up by Michael Henson here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>, continued here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>). Joe Groff convinced <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me that lenses are a better approach for working with getters/setters, so I've dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>Motivation

It's fairly common in Swift for multiple functions or methods to have the same "base name", but be distinguished by parameter labels. For example, UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}
which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to ask for the Objective-C selector for a given method (rather than writing a string literal). The argument to such an operation would likely be a reference to a method, which would benefit from being able to name any method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed solution

I propose to extend function naming to allow compound Swift names (e.g., insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)
let fn1 = someView.insertSubview(_:aboveSubview:)
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)
The "produce the Objective-C selector for the given method" operation will be the subject of a separate proposal. However, here is one possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed Design

Grammatically, the primary-expression grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]
to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
Within the parentheses, the use of "+" is important, because it disambiguates:

f()
as a call to f rather than a reference to an f with no arguments. Zero-argument function references will still require disambiguation via contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives considered

Joe Groff notes <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> that lenses are a better solution than manually retrieving getter/setter functions when the intent is to actually operate on the properties.

Bartlomiej Cichosz suggests <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a general partial application syntax using _ as a placeholder, e.g.,

aGameView.insertSubview(_, aboveSubview: playingSurfaceView)
When all arguments are _, this provides the ability to name any method:

aGameView.insertSubview(_, aboveSubview: _)
I decided not to go with this because I don't believe we need such a general partial application syntax in Swift. Closures using the $ names are nearly as concise, and eliminate any questions about how the _ placeholder maps to an argument of the partially-applied function:

{ aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

  - Doug

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


(David Owens II) #3

I like the proposal. It does illustrate one of the naming conventions I really dislike with Swift (implicitly unnamed first parameter).

let fn1 = someView.insert(subview:aboveSubview:)

Would have looked so much better. =)

Anyhow, +1 for the proposal.

-David

···

On Jan 11, 2016, at 11:03 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md


(TJ Usiyan) #4

I thought that the backpacks were workable but this does look nicer.

Is there any way to specify which module/framework you are pulling the
selector from? Is that information even part of the selector? Am I
overestimated the usefulness of that possibility?

TJ

···

On Mon, Jan 11, 2016 at 2:03 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function”
proposal to only deal with naming functions with argument labels, and
dropping the back-ticks. Comments welcome! Proposal is here

https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

   - Proposal: SE-NNNN
   <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
   - Author(s): Doug Gregor <https://github.com/DougGregor>
   - Status: *Awaiting Review*
   - Review manager: TBD

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>
Introduction

Swift includes support for first-class functions, such that any function
(or method) can be placed into a value of function type. However, when
specifying the name of a function, one can only provide the base name,
(e.g., insertSubview) without the argument labels. For overloaded
functions, this means that one must disambiguate based on type information,
which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a
Swift program---one cannot provide the argument labels when naming a
function, nor are property and subscript getters and setters referenceable.
This proposal introduces a general syntax that allows one to name anything
that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed
here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>.
It included support for naming getters/setters (separately brought up by
Michael Henson here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>,
continued here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>).
Joe Groff convinced
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me
that lenses are a better approach for working with getters/setters, so I've
dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>
Motivation

It's fairly common in Swift for multiple functions or methods to have the
same "base name", but be distinguished by parameter labels. For example,
UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}

When calling these methods, the argument labels distinguish the different
methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)

However, when referencing the function to create a function value, one
cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods

In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!

To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}

which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to
ask for the Objective-C selector for a given method (rather than writing a
string literal). The argument to such an operation would likely be a
reference to a method, which would benefit from being able to name any
method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed
solution

I propose to extend function naming to allow compound Swift names (e.g.,
insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)let fn1 = someView.insertSubview(_:aboveSubview:)

The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)

The "produce the Objective-C selector for the given method" operation will
be the subject of a separate proposal. However, here is one possibility
that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed
Design

Grammatically, the *primary-expression* grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]

to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'

Within the parentheses, the use of "+" is important, because it
disambiguates:

f()

as a call to f rather than a reference to an f with no arguments.
Zero-argument function references will still require disambiguation via
contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact
on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives
considered

   -

   Joe Groff notes
   <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html>
    that *lenses* are a better solution than manually retrieving
   getter/setter functions when the intent is to actually operate on the
   properties.
   -

   Bartlomiej Cichosz suggests
   <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a
   general partial application syntax using _ as a placeholder, e.g.,

   aGameView.insertSubview(_, aboveSubview: playingSurfaceView)

   When all arguments are _, this provides the ability to name any method:

   aGameView.insertSubview(_, aboveSubview: _)

   I decided not to go with this because I don't believe we need such a
   general partial application syntax in Swift. Closures using the $ names are
   nearly as concise, and eliminate any questions about how the _ placeholder
   maps to an argument of the partially-applied function:

   { aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

- Doug

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


(Tino) #5

I haven't had issues with ambiguous function names, but it just feels odd that there is no elegant way to solve those problems, so I agree that something should be done here.

Speaking of the details, "(" always is an indication to me that there is a function to be called (not only referenced). Are there any special reasons for the parenthesis in this context?
Wouldn't parsing be easier when we just leave out "(", ")" and "_"?
let fn1 = someView.insertSubview:aboveSubview:
imho looks better.

Best regards,
Tino


(Janosch Hildebrand) #6

This is looking great and I'm happy that the back-ticks are gone.

And just as a quick aside on the proposal text, something probably went amiss between these two sentences:

This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program

- Janosch


(Wallacy) #7

+1 from me as well! This version looks pretty good.

···

Em seg, 11 de jan de 2016 às 17:03, Douglas Gregor via swift-evolution < swift-evolution@swift.org> escreveu:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function”
proposal to only deal with naming functions with argument labels, and
dropping the back-ticks. Comments welcome! Proposal is here

https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

   - Proposal: SE-NNNN
   <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
   - Author(s): Doug Gregor <https://github.com/DougGregor>
   - Status: *Awaiting Review*
   - Review manager: TBD

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>
Introduction

Swift includes support for first-class functions, such that any function
(or method) can be placed into a value of function type. However, when
specifying the name of a function, one can only provide the base name,
(e.g., insertSubview) without the argument labels. For overloaded
functions, this means that one must disambiguate based on type information,
which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a
Swift program---one cannot provide the argument labels when naming a
function, nor are property and subscript getters and setters referenceable.
This proposal introduces a general syntax that allows one to name anything
that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed
here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>.
It included support for naming getters/setters (separately brought up by
Michael Henson here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>,
continued here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>).
Joe Groff convinced
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me
that lenses are a better approach for working with getters/setters, so I've
dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>
Motivation

It's fairly common in Swift for multiple functions or methods to have the
same "base name", but be distinguished by parameter labels. For example,
UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}

When calling these methods, the argument labels distinguish the different
methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)

However, when referencing the function to create a function value, one
cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods

In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!

To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}

which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to
ask for the Objective-C selector for a given method (rather than writing a
string literal). The argument to such an operation would likely be a
reference to a method, which would benefit from being able to name any
method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed
solution

I propose to extend function naming to allow compound Swift names (e.g.,
insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)let fn1 = someView.insertSubview(_:aboveSubview:)

The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)

The "produce the Objective-C selector for the given method" operation will
be the subject of a separate proposal. However, here is one possibility
that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed
Design

Grammatically, the *primary-expression* grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]

to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'

Within the parentheses, the use of "+" is important, because it
disambiguates:

f()

as a call to f rather than a reference to an f with no arguments.
Zero-argument function references will still require disambiguation via
contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact
on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives
considered

   -

   Joe Groff notes
   <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html>
    that *lenses* are a better solution than manually retrieving
   getter/setter functions when the intent is to actually operate on the
   properties.
   -

   Bartlomiej Cichosz suggests
   <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a
   general partial application syntax using _ as a placeholder, e.g.,

   aGameView.insertSubview(_, aboveSubview: playingSurfaceView)

   When all arguments are _, this provides the ability to name any method:

   aGameView.insertSubview(_, aboveSubview: _)

   I decided not to go with this because I don't believe we need such a
   general partial application syntax in Swift. Closures using the $ names are
   nearly as concise, and eliminate any questions about how the _ placeholder
   maps to an argument of the partially-applied function:

   { aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

- Doug

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


(Rudolf Adamkovič) #8

Doug, what a fantastic job.

Can't wait to see this happen!

R+

···

Sent from my iPhone

On 11 Jan 2016, at 20:03, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels
Proposal: SE-NNNN
Author(s): Doug Gregor
Status: Awaiting Review
Review manager: TBD
Introduction

Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, when specifying the name of a function, one can only provide the base name, (e.g., insertSubview) without the argument labels. For overloaded functions, this means that one must disambiguate based on type information, which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program---one cannot provide the argument labels when naming a function, nor are property and subscript getters and setters referenceable. This proposal introduces a general syntax that allows one to name anything that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed here. It included support for naming getters/setters (separately brought up by Michael Henson here, continued here). Joe Groff convinced me that lenses are a better approach for working with getters/setters, so I've dropped them from this version of the proposal.

Motivation

It's fairly common in Swift for multiple functions or methods to have the same "base name", but be distinguished by parameter labels. For example, UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}
which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to ask for the Objective-C selector for a given method (rather than writing a string literal). The argument to such an operation would likely be a reference to a method, which would benefit from being able to name any method, including getters and setters.

Proposed solution

I propose to extend function naming to allow compound Swift names (e.g., insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)
let fn1 = someView.insertSubview(_:aboveSubview:)
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)
The "produce the Objective-C selector for the given method" operation will be the subject of a separate proposal. However, here is one possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.
Detailed Design

Grammatically, the primary-expression grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]
to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
Within the parentheses, the use of "+" is important, because it disambiguates:

f()
as a call to f rather than a reference to an f with no arguments. Zero-argument function references will still require disambiguation via contextual type information.

Impact on existing code

This is a purely additive feature that has no impact on existing code.

Alternatives considered

Joe Groff notes that lenses are a better solution than manually retrieving getter/setter functions when the intent is to actually operate on the properties.

Bartlomiej Cichosz suggests a general partial application syntax using _ as a placeholder, e.g.,

aGameView.insertSubview(_, aboveSubview: playingSurfaceView)
When all arguments are _, this provides the ability to name any method:

aGameView.insertSubview(_, aboveSubview: _)
I decided not to go with this because I don't believe we need such a general partial application syntax in Swift. Closures using the $ names are nearly as concise, and eliminate any questions about how the _ placeholder maps to an argument of the partially-applied function:

{ aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

  - Doug

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


(Patrick Gili) #9

One thing that stands out about this proposal. The syntax you have proposed to name functions aligns nicely with the documentation that Apple has been publishing for Swift. When first reading the documentation, this can take some time to assimilate, especially since it was abstract. This proposal would make this syntax more concrete, and I think it might help beginners to better understand Swift functions. Hence, I fully support this proposal.

Cheers,
-Patrick

···

On Jan 11, 2016, at 2:03 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
Author(s): Doug Gregor <https://github.com/DougGregor>
Status: Awaiting Review
Review manager: TBD
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>Introduction

Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, when specifying the name of a function, one can only provide the base name, (e.g., insertSubview) without the argument labels. For overloaded functions, this means that one must disambiguate based on type information, which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program---one cannot provide the argument labels when naming a function, nor are property and subscript getters and setters referenceable. This proposal introduces a general syntax that allows one to name anything that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>. It included support for naming getters/setters (separately brought up by Michael Henson here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>, continued here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>). Joe Groff convinced <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me that lenses are a better approach for working with getters/setters, so I've dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>Motivation

It's fairly common in Swift for multiple functions or methods to have the same "base name", but be distinguished by parameter labels. For example, UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}
which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to ask for the Objective-C selector for a given method (rather than writing a string literal). The argument to such an operation would likely be a reference to a method, which would benefit from being able to name any method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed solution

I propose to extend function naming to allow compound Swift names (e.g., insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)
let fn1 = someView.insertSubview(_:aboveSubview:)
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)
The "produce the Objective-C selector for the given method" operation will be the subject of a separate proposal. However, here is one possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed Design

Grammatically, the primary-expression grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]
to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
Within the parentheses, the use of "+" is important, because it disambiguates:

f()
as a call to f rather than a reference to an f with no arguments. Zero-argument function references will still require disambiguation via contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives considered

Joe Groff notes <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> that lenses are a better solution than manually retrieving getter/setter functions when the intent is to actually operate on the properties.

Bartlomiej Cichosz suggests <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a general partial application syntax using _ as a placeholder, e.g.,

aGameView.insertSubview(_, aboveSubview: playingSurfaceView)
When all arguments are _, this provides the ability to name any method:

aGameView.insertSubview(_, aboveSubview: _)
I decided not to go with this because I don't believe we need such a general partial application syntax in Swift. Closures using the $ names are nearly as concise, and eliminate any questions about how the _ placeholder maps to an argument of the partially-applied function:

{ aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

  - Doug

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


(Douglas Gregor) #10

I thought that the backpacks were workable but this does look nicer.

Backticks were workable and general but ugly.

Is there any way to specify which module/framework you are pulling the selector from? Is that information even part of the selector? Am I overestimated the usefulness of that possibility?

This is about naming functions. You can use “modulename.fnname(arglabel1:arglabel2:)” to name a specific function from a module.

  - Doug

···

On Jan 11, 2016, at 11:12 AM, T.J. Usiyan <griotspeak@gmail.com> wrote:

TJ

On Mon, Jan 11, 2016 at 2:03 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
Author(s): Doug Gregor <https://github.com/DougGregor>
Status: Awaiting Review
Review manager: TBD
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>Introduction

Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, when specifying the name of a function, one can only provide the base name, (e.g., insertSubview) without the argument labels. For overloaded functions, this means that one must disambiguate based on type information, which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program---one cannot provide the argument labels when naming a function, nor are property and subscript getters and setters referenceable. This proposal introduces a general syntax that allows one to name anything that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>. It included support for naming getters/setters (separately brought up by Michael Henson here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>, continued here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>). Joe Groff convinced <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me that lenses are a better approach for working with getters/setters, so I've dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>Motivation

It's fairly common in Swift for multiple functions or methods to have the same "base name", but be distinguished by parameter labels. For example, UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}
which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to ask for the Objective-C selector for a given method (rather than writing a string literal). The argument to such an operation would likely be a reference to a method, which would benefit from being able to name any method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed solution

I propose to extend function naming to allow compound Swift names (e.g., insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)
let fn1 = someView.insertSubview(_:aboveSubview:)
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)
The "produce the Objective-C selector for the given method" operation will be the subject of a separate proposal. However, here is one possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed Design

Grammatically, the primary-expression grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]
to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
Within the parentheses, the use of "+" is important, because it disambiguates:

f()
as a call to f rather than a reference to an f with no arguments. Zero-argument function references will still require disambiguation via contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives considered

Joe Groff notes <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> that lenses are a better solution than manually retrieving getter/setter functions when the intent is to actually operate on the properties.

Bartlomiej Cichosz suggests <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a general partial application syntax using _ as a placeholder, e.g.,

aGameView.insertSubview(_, aboveSubview: playingSurfaceView)
When all arguments are _, this provides the ability to name any method:

aGameView.insertSubview(_, aboveSubview: _)
I decided not to go with this because I don't believe we need such a general partial application syntax in Swift. Closures using the $ names are nearly as concise, and eliminate any questions about how the _ placeholder maps to an argument of the partially-applied function:

{ aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

  - Doug

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


(Douglas Gregor) #11

I haven't had issues with ambiguous function names, but it just feels odd that there is no elegant way to solve those problems, so I agree that something should be done here.

Speaking of the details, "(" always is an indication to me that there is a function to be called (not only referenced). Are there any special reasons for the parenthesis in this context?

That’s how we write Swift function names: basename(arglabel1:arglabel2:…arglabelN:).

Wouldn't parsing be easier when we just leave out "(", ")" and "_”?

Parsing is easy either way.

let fn1 = someView.insertSubview:aboveSubview:
imho looks better.

Sometimes the first argument has a label, so just dropping it doesn’t actually work. It would have to be

  let fn1 = someView.insertSubview:_:aboveSubview:

or

  let fn1 = someView.insertSubview::aboveSubview:

which looks almost like the Objective-C selector, but isn’t. And it doesn’t match the way these methods are called.

  - Doug

···

On Jan 11, 2016, at 11:38 AM, Tino Heth <2th@gmx.de> wrote:


(Douglas Gregor) #12

Whoops, thanks!

  - Doug

···

On Jan 11, 2016, at 12:48 PM, Janosch Hildebrand <jnosh@jnosh.com> wrote:

This is looking great and I'm happy that the back-ticks are gone.

And just as a quick aside on the proposal text, something probably went amiss between these two sentences:

This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program

- Janosch


(Douglas Gregor) #13

SGTM. A few points I didn't see addressed from the last thread:

- Do we need the '_' representing unlabeled arguments? 'foo(:bar:)' should be workable, as in ObjC.

We discussed this a looooong while back and decided that we wanted the ‘_’ to emphasize that there is an argument there. The difference between “foo(:bar:)” and “foo(bar:)” is barely visible.

- How do references to defaulted or variadic arguments work? Do you have to reference their labels completely in declared order, or could you refer to 'func foo(x: Int = 5, y: String = "")' as 'foo(y:x:)', 'foo(x:)', and/or 'foo(y:)' as well?

You have to reference their labels completely in declared order; that’s the name of the method.

  - Doug

···

On Jan 11, 2016, at 12:49 PM, Joe Groff <jgroff@apple.com> wrote:

-Joe

On Jan 11, 2016, at 11:03 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
Author(s): Doug Gregor <https://github.com/DougGregor>
Status: Awaiting Review
Review manager: TBD
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>Introduction

Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, when specifying the name of a function, one can only provide the base name, (e.g., insertSubview) without the argument labels. For overloaded functions, this means that one must disambiguate based on type information, which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program---one cannot provide the argument labels when naming a function, nor are property and subscript getters and setters referenceable. This proposal introduces a general syntax that allows one to name anything that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>. It included support for naming getters/setters (separately brought up by Michael Henson here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>, continued here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>). Joe Groff convinced <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me that lenses are a better approach for working with getters/setters, so I've dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>Motivation

It's fairly common in Swift for multiple functions or methods to have the same "base name", but be distinguished by parameter labels. For example, UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}
which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to ask for the Objective-C selector for a given method (rather than writing a string literal). The argument to such an operation would likely be a reference to a method, which would benefit from being able to name any method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed solution

I propose to extend function naming to allow compound Swift names (e.g., insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)
let fn1 = someView.insertSubview(_:aboveSubview:)
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)
The "produce the Objective-C selector for the given method" operation will be the subject of a separate proposal. However, here is one possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed Design

Grammatically, the primary-expression grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]
to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
Within the parentheses, the use of "+" is important, because it disambiguates:

f()
as a call to f rather than a reference to an f with no arguments. Zero-argument function references will still require disambiguation via contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives considered

Joe Groff notes <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> that lenses are a better solution than manually retrieving getter/setter functions when the intent is to actually operate on the properties.

Bartlomiej Cichosz suggests <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a general partial application syntax using _ as a placeholder, e.g.,

aGameView.insertSubview(_, aboveSubview: playingSurfaceView)
When all arguments are _, this provides the ability to name any method:

aGameView.insertSubview(_, aboveSubview: _)
I decided not to go with this because I don't believe we need such a general partial application syntax in Swift. Closures using the $ names are nearly as concise, and eliminate any questions about how the _ placeholder maps to an argument of the partially-applied function:

{ aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

  - Doug

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


(TJ Usiyan) #14

Thanks for the clarification.

···

On Mon, Jan 11, 2016 at 2:13 PM, Douglas Gregor <dgregor@apple.com> wrote:

On Jan 11, 2016, at 11:12 AM, T.J. Usiyan <griotspeak@gmail.com> wrote:

I thought that the backpacks were workable but this does look nicer.

Backticks were workable and general but ugly.

Is there any way to specify which module/framework you are pulling the
selector from? Is that information even part of the selector? Am I
overestimated the usefulness of that possibility?

This is about naming functions. You can use
“modulename.fnname(arglabel1:arglabel2:)” to name a specific function from
a module.

- Doug

TJ

On Mon, Jan 11, 2016 at 2:03 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function”
proposal to only deal with naming functions with argument labels, and
dropping the back-ticks. Comments welcome! Proposal is here

https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

   - Proposal: SE-NNNN
   <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
   - Author(s): Doug Gregor <https://github.com/DougGregor>
   - Status: *Awaiting Review*
   - Review manager: TBD

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>
Introduction

Swift includes support for first-class functions, such that any function
(or method) can be placed into a value of function type. However, when
specifying the name of a function, one can only provide the base name,
(e.g., insertSubview) without the argument labels. For overloaded
functions, this means that one must disambiguate based on type information,
which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a
Swift program---one cannot provide the argument labels when naming a
function, nor are property and subscript getters and setters referenceable.
This proposal introduces a general syntax that allows one to name anything
that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed
here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>.
It included support for naming getters/setters (separately brought up by
Michael Henson here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>,
continued here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>).
Joe Groff convinced
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me
that lenses are a better approach for working with getters/setters, so I've
dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>
Motivation

It's fairly common in Swift for multiple functions or methods to have the
same "base name", but be distinguished by parameter labels. For example,
UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}

When calling these methods, the argument labels distinguish the different
methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)

However, when referencing the function to create a function value, one
cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods

In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!

To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}

which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to
ask for the Objective-C selector for a given method (rather than writing a
string literal). The argument to such an operation would likely be a
reference to a method, which would benefit from being able to name any
method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed
solution

I propose to extend function naming to allow compound Swift names (e.g.,
insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)let fn1 = someView.insertSubview(_:aboveSubview:)

The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)

The "produce the Objective-C selector for the given method" operation
will be the subject of a separate proposal. However, here is one
possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed
Design

Grammatically, the *primary-expression* grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]

to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'

Within the parentheses, the use of "+" is important, because it
disambiguates:

f()

as a call to f rather than a reference to an f with no arguments.
Zero-argument function references will still require disambiguation via
contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact
on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives
considered

   -

   Joe Groff notes
   <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html>
    that *lenses* are a better solution than manually retrieving
   getter/setter functions when the intent is to actually operate on the
   properties.
   -

   Bartlomiej Cichosz suggests
   <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a
   general partial application syntax using _ as a placeholder, e.g.,

   aGameView.insertSubview(_, aboveSubview: playingSurfaceView)

   When all arguments are _, this provides the ability to name any
   method:

   aGameView.insertSubview(_, aboveSubview: _)

   I decided not to go with this because I don't believe we need such a
   general partial application syntax in Swift. Closures using the $ names are
   nearly as concise, and eliminate any questions about how the _ placeholder
   maps to an argument of the partially-applied function:

   { aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

- Doug

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


(Félix Cloutier) #15

I agree that a lot of developers might not end up using partial application if we went with Bartlomiej Cichosz's. However, it seems to me that the cost difference between his suggestion and the main one is very small, and partial application is definitely a lot more powerful. I find it pretty relevant considering that the special syntax for curried functions is going away. One parameter per underscore covers most use cases and you can fall back to closures if you need to.

I think that the current proposal is better than the statu quo, but I like that other solution best.

Félix

···

Le 11 janv. 2016 à 14:13:43, Douglas Gregor via swift-evolution <swift-evolution@swift.org> a écrit :

On Jan 11, 2016, at 11:12 AM, T.J. Usiyan <griotspeak@gmail.com <mailto:griotspeak@gmail.com>> wrote:

I thought that the backpacks were workable but this does look nicer.

Backticks were workable and general but ugly.

Is there any way to specify which module/framework you are pulling the selector from? Is that information even part of the selector? Am I overestimated the usefulness of that possibility?

This is about naming functions. You can use “modulename.fnname(arglabel1:arglabel2:)” to name a specific function from a module.

  - Doug

TJ

On Mon, Jan 11, 2016 at 2:03 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
Author(s): Doug Gregor <https://github.com/DougGregor>
Status: Awaiting Review
Review manager: TBD
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>Introduction

Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, when specifying the name of a function, one can only provide the base name, (e.g., insertSubview) without the argument labels. For overloaded functions, this means that one must disambiguate based on type information, which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program---one cannot provide the argument labels when naming a function, nor are property and subscript getters and setters referenceable. This proposal introduces a general syntax that allows one to name anything that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>. It included support for naming getters/setters (separately brought up by Michael Henson here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>, continued here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>). Joe Groff convinced <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me that lenses are a better approach for working with getters/setters, so I've dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>Motivation

It's fairly common in Swift for multiple functions or methods to have the same "base name", but be distinguished by parameter labels. For example, UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}
which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to ask for the Objective-C selector for a given method (rather than writing a string literal). The argument to such an operation would likely be a reference to a method, which would benefit from being able to name any method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed solution

I propose to extend function naming to allow compound Swift names (e.g., insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)
let fn1 = someView.insertSubview(_:aboveSubview:)
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)
The "produce the Objective-C selector for the given method" operation will be the subject of a separate proposal. However, here is one possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed Design

Grammatically, the primary-expression grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]
to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
Within the parentheses, the use of "+" is important, because it disambiguates:

f()
as a call to f rather than a reference to an f with no arguments. Zero-argument function references will still require disambiguation via contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives considered

Joe Groff notes <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> that lenses are a better solution than manually retrieving getter/setter functions when the intent is to actually operate on the properties.

Bartlomiej Cichosz suggests <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a general partial application syntax using _ as a placeholder, e.g.,

aGameView.insertSubview(_, aboveSubview: playingSurfaceView)
When all arguments are _, this provides the ability to name any method:

aGameView.insertSubview(_, aboveSubview: _)
I decided not to go with this because I don't believe we need such a general partial application syntax in Swift. Closures using the $ names are nearly as concise, and eliminate any questions about how the _ placeholder maps to an argument of the partially-applied function:

{ aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

  - Doug

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

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


(Matthew Johnson) #16

I like the proposal. It does illustrate one of the naming conventions I really dislike with Swift (implicitly unnamed first parameter).

let fn1 = someView.insert(subview:aboveSubview:)

Would have looked so much better. =)

I agree in this case, although there may be cases where unnamed arguments are still better. This seems like it is at least partly a problem with how existing Cocoa APIs are imported.

Anyhow, +1 for the proposal.

Agree. +1 from me as well. This looks really good.

Now I’m looking forward to seeing more about lenses so we can also work with getters, setters, and subscripts.

Matthew

···

On Jan 11, 2016, at 3:42 PM, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

-David

On Jan 11, 2016, at 11:03 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

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


(Douglas Gregor) #17

I agree that a lot of developers might not end up using partial application if we went with Bartlomiej Cichosz's. However, it seems to me that the cost difference between his suggestion and the main one is very small, and partial application is definitely a lot more powerful.

Implementing generalized partial application is significantly more complicated than what I’m proposing.

I find it pretty relevant considering that the special syntax for curried functions is going away.

I don’t see how it’s related at all. That’s about removing special syntax for declaring curried functions; this is about naming in references to functions.

One parameter per underscore covers most use cases and you can fall back to closures if you need to.

This doesn’t seem like an area that benefits from Yet Another Intermediate Syntax.

  - Doug

···

On Jan 11, 2016, at 11:44 AM, Félix Cloutier <felixcca@yahoo.ca> wrote:

I think that the current proposal is better than the statu quo, but I like that other solution best.

Félix

Le 11 janv. 2016 à 14:13:43, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

On Jan 11, 2016, at 11:12 AM, T.J. Usiyan <griotspeak@gmail.com <mailto:griotspeak@gmail.com>> wrote:

I thought that the backpacks were workable but this does look nicer.

Backticks were workable and general but ugly.

Is there any way to specify which module/framework you are pulling the selector from? Is that information even part of the selector? Am I overestimated the usefulness of that possibility?

This is about naming functions. You can use “modulename.fnname(arglabel1:arglabel2:)” to name a specific function from a module.

  - Doug

TJ

On Mon, Jan 11, 2016 at 2:03 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

I’ve updated and simplified my “Generalized Naming for Any Function” proposal to only deal with naming functions with argument labels, and dropping the back-ticks. Comments welcome! Proposal is here

  https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md

and inline:

Naming Functions with Argument Labels

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md>
Author(s): Doug Gregor <https://github.com/DougGregor>
Status: Awaiting Review
Review manager: TBD
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#introduction>Introduction

Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, when specifying the name of a function, one can only provide the base name, (e.g., insertSubview) without the argument labels. For overloaded functions, this means that one must disambiguate based on type information, which is awkward and verbose. This proposal allwos one

it is not possible to specifically name every function that is part of a Swift program---one cannot provide the argument labels when naming a function, nor are property and subscript getters and setters referenceable. This proposal introduces a general syntax that allows one to name anything that is a function within Swift in an extensible manner.

Swift-evolution thread: The first draft of this proposal was discussed here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html>. It included support for naming getters/setters (separately brought up by Michael Henson here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>, continued here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>). Joe Groff convinced <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004579.html> me that lenses are a better approach for working with getters/setters, so I've dropped them from this version of the proposal.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#motivation>Motivation

It's fairly common in Swift for multiple functions or methods to have the same "base name", but be distinguished by parameter labels. For example, UIView has three methods with the same base name insertSubview:

extension UIView {
  func insertSubview(view: UIView, at index: Int)
  func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
  func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
}
When calling these methods, the argument labels distinguish the different methods, e.g.,

someView.insertSubview(view, at: 3)
someView.insertSubview(view, aboveSubview: otherView)
someView.insertSubview(view, belowSubview: otherView)
However, when referencing the function to create a function value, one cannot provide the labels:

let fn = someView.insertSubview // ambiguous: could be any of the three methods
In some cases, it is possible to use type annotations to disambiguate:

let fn: (UIView, Int) = someView.insertSubview // ok: uses insertSubview(_:at:)
let fn: (UIView, UIView) = someView.insertSubview // error: still ambiguous!
To resolve the latter case, one must fall back to creating a closure:

let fn: (UIView, UIView) = { view, otherView in
  button.insertSubview(view, aboveSubview: otherView)
}
which is painfully tedious.

One additional bit of motivation: Swift should probably get some way to ask for the Objective-C selector for a given method (rather than writing a string literal). The argument to such an operation would likely be a reference to a method, which would benefit from being able to name any method, including getters and setters.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#proposed-solution>Proposed solution

I propose to extend function naming to allow compound Swift names (e.g., insertSubview(_:aboveSubview:)) anywhere a name can occur. Specifically,

let fn = someView.insertSubview(_:at:)
let fn1 = someView.insertSubview(_:aboveSubview:)
The same syntax can also refer to initializers, e.g.,

let buttonFactory = UIButton.init(type:)
The "produce the Objective-C selector for the given method" operation will be the subject of a separate proposal. However, here is one possibility that illustrations how it uses the proposed syntax here:

let getter = Selector(NSDictionary.insertSubview(_:aboveSubview:)) // produces insertSubview:aboveSubview:.
<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#detailed-design>Detailed Design

Grammatically, the primary-expression grammar will change from:

primary-expression -> identifier generic-argument-clause[opt]
to:

primary-expression -> unqualified-name generic-argument-clause[opt]

unqualified-name -> identifier
                  > identifier '(' ((identifier | '_') ':')+ ')'
Within the parentheses, the use of "+" is important, because it disambiguates:

f()
as a call to f rather than a reference to an f with no arguments. Zero-argument function references will still require disambiguation via contextual type information.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#impact-on-existing-code>Impact on existing code

This is a purely additive feature that has no impact on existing code.

<https://github.com/DougGregor/swift-evolution/tree/generalized-naming#alternatives-considered>Alternatives considered

Joe Groff notes <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> that lenses are a better solution than manually retrieving getter/setter functions when the intent is to actually operate on the properties.

Bartlomiej Cichosz suggests <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html> a general partial application syntax using _ as a placeholder, e.g.,

aGameView.insertSubview(_, aboveSubview: playingSurfaceView)
When all arguments are _, this provides the ability to name any method:

aGameView.insertSubview(_, aboveSubview: _)
I decided not to go with this because I don't believe we need such a general partial application syntax in Swift. Closures using the $ names are nearly as concise, and eliminate any questions about how the _ placeholder maps to an argument of the partially-applied function:

{ aGameView.insertSubview($0, aboveSubview: playingSurfaceView) }

  - Doug

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

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


(Tino) #18

We discussed this a looooong while back and decided that we wanted the ‘_’ to emphasize that there is an argument there. The difference between “foo(:bar:)” and “foo(bar:)” is barely visible.

That is true, but I think it is very uncommon to have such a set of methods — and afaics, it would violate the guidelines for method names.

But speaking of additional characters that might be useful:
What about the parameter types? When they are needed to identify the exact function, it would be nice if they could be included as well.

foo(bar:(Int))
(that's why I wanted to avoid the parenthesis in the first place…)

Tino


(Douglas Gregor) #19

It’s grammatically ambiguous if you don’t have the “:)” at the end and, IMO, it’s not important enough to have special syntax for this: one can still coerce to a specific function type.

  - Doug

···

On Jan 11, 2016, at 1:53 PM, Tino Heth <2th@gmx.de> wrote:

We discussed this a looooong while back and decided that we wanted the ‘_’ to emphasize that there is an argument there. The difference between “foo(:bar:)” and “foo(bar:)” is barely visible.

That is true, but I think it is very uncommon to have such a set of methods — and afaics, it would violate the guidelines for method names.

But speaking of additional characters that might be useful:
What about the parameter types? When they are needed to identify the exact function, it would be nice if they could be included as well.

foo(bar:(Int))
(that's why I wanted to avoid the parenthesis in the first place…)


(Brent Royal-Gordon) #20

foo(bar:(Int))
(that's why I wanted to avoid the parenthesis in the first place…)

It’s grammatically ambiguous if you don’t have the “:)” at the end

Is it? It's not legal to pass a type name—`foo(bar: Int)` is not legal code; you have to say `foo(bar: Int.self)`.

···

--
Brent Royal-Gordon
Architechies