Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[plx via swift-evolution]

I like this proposal overall and the proposed syntax in particular; I think it 
addresses a real issue in a straightforward, predictable way.

As an aside — and FWIW — one thing I was at some point going to propose was a 
shorthand syntax for specifying trivial “argument-ordering-adjustment” closures.

EG: in the context of the proposal, a shorthand like this:

let indicesForViews: [(Int,UIView)] = …
indicesForViews.forEach(self.`insertSubview($1,at:$0)`)

…although using something other than back-ticks may be necessary to avoid 
ambiguity.

In the example above, it’s a bit contrived; in general, it’s never 
actually-shorter than the current option:

let indicesForViews: [(Int,UIView)] = …
indicesForViews.forEach({ self.insertSubview($1, at: $0) })

…but it would still make things more symmetric between the “function name” case 
and the inline-short-closure case.

More importantly, it’d allow a streamlined way to express things like this:

// shorthand:
let flippedArguments = self.`insertSubview($1, at: $0)` 

// current syntax:
let flippedArguments = { (Int,UIView) -> Void in self.insertSubview($1, 
at: $0) }

…which will be a lot more useful once we have a reliable way to pull such 
functions into local variables.

I’m not requesting this be included in the below proposal, just hoping the 
final syntax selected here not somehow inadvertently prevent such a construct 
from ever being created.

Apologies if this has already come up in the discussion.

> On Dec 27, 2015, at 1:22 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a proposal draft to allow one to name any function in Swift. In 
> effect, it’s continuing the discussion of retrieving getters and setters as 
> functions started by Michael Henson here:
> 
>   
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>  
> 
> 
> the proposal follows, and is available here as well:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>  
> 
> 
> Comments appreciated!
> 
> Generalized Naming for Any Function
> 
> Proposal: SE- 
> 
> 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, 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: Michael Henson started a thread about the 
> getter/setter issue here 
> ,
>  continued here 
> .
>  See the Alternatives considered 
> 
>  section for commentary on that discussion.
> 
>  
> 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: 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Joe Groff via swift-evolution]

We also have a problem with disambiguating same-named members that come from 
different extensions, whether via protocol extensions or independent concrete 
extensions from different modules. Could we extend this scheme to allow for 
disambiguating extension methods by protocol/module name?

extension ProtocolA { func foo() }
extension ProtocolB { func foo() }

public struct Foo: ProtocolA, ProtocolB {
  func callBothFoos() {
self.`ProtocolA.foo`()
self.`ProtocolB.foo`()
  }
}

import A // extends Bar with bar()
import B // also extends Bar with bar()

extension Bar {
  func callBothBars() {
self.`A.bar`()
self.`B.bar`()
  }
}

-Joe

> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a proposal draft to allow one to name any function in Swift. In 
> effect, it’s continuing the discussion of retrieving getters and setters as 
> functions started by Michael Henson here:
> 
>   
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>  
> 
> 
> the proposal follows, and is available here as well:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>  
> 
> 
> Comments appreciated!
> 
> Generalized Naming for Any Function
> 
> Proposal: SE- 
> 
> 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, 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: Michael Henson started a thread about the 
> getter/setter issue here 
> ,
>  continued here 
> .
>  See the Alternatives considered 
> 
>  section for commentary on that discussion.
> 
>  
> 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, otherView)
> }
> which is painfully tedious. A similar workaround is required to produce a 
> function value for a getter of a property, e.g.,
> 
> extension UIButton {
>   var currentTitle: String? { ... }
> }
> 
> var fn: () -> String? = { () in
>   return button.currentTitle
> }
> 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.
> 
>  
> 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Bartlomiej Cichosz via swift-evolution]

Hi,

I am sorry if this was already considered (jumping in a bit late), but what 
about using the following syntax:

let fn = aGameView.insertSubview(_, aboveSubview: _)

This is similar to a function calling syntax (rather than function definition 
syntax), but with _ instead of specific arguments.

The reason I think this may be useful is because it could be generalized to a 
syntax for partial application (assuming such functionality is desired in 
Swift):

let insertCardViewAtTheBottomOfTheDeck = aGameView.insertSubview(_, 
aboveSubview: playingSurfaceView)

then:

insertCardViewAtTheBottomOfTheDeck(anotherCard)


Or:

let insertMyCard = aGameView.insertSubview(myCard, aboveSubview: _)

then:

insertMyCard(aboveSubview:otherCard)


In the above examples, the definitions of insertCardViewAtTheBottomOfTheDeck 
and insertMyCard would return partially applied functions. Whereas the first 
example, the definition of fn, where all arguments are specified as _ is a 
special case that refers to the original function.

Some of the issues mentioned in the proposal remain, for example, how to 
disambiguate same function names with different parameter types, such as:

let fn1 = aGameView.insertSubview(_, aboveSubview: _:CardView)

or 

let fn2 = aGameView.insertSubview(_, aboveSubview: _ as CardView)



Or different return values:

let fn3 = aGameView.insertSubview(_, aboveSubview: playingSurfaceView) -> Bool


Getters and setters, using the example from the proposal:

let getRow = someMatrix.subscript(row: _).get


All of the above assumes, of course, that presence of one or more _ is 
sufficient to parse these not as function calls, but partial application 
expressions (with the special case of all _s being just reference to the 
original function). If that’s the case, it would eliminate the need for 
back-ticks.

Regards,

Bart



> On Dec 27, 2015, at 02:22, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a proposal draft to allow one to name any function in Swift. In 
> effect, it’s continuing the discussion of retrieving getters and setters as 
> functions started by Michael Henson here:
> 
>   
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>  
> 
> 
> the proposal follows, and is available here as well:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>  
> 
> 
> Comments appreciated!
> 
> Generalized Naming for Any Function
> 
> Proposal: SE- 
> 
> 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, 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: Michael Henson started a thread about the 
> getter/setter issue here 
> ,
>  continued here 
> .
>  See the Alternatives considered 
> 
>  section for commentary on that discussion.
> 
>  
> 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 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Matthew Johnson via swift-evolution]

> On Dec 29, 2015, at 12:17 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> We also have a problem with disambiguating same-named members that come from 
> different extensions, whether via protocol extensions or independent concrete 
> extensions from different modules. Could we extend this scheme to allow for 
> disambiguating extension methods by protocol/module name?
> 
> extension ProtocolA { func foo() }
> extension ProtocolB { func foo() }
> 
> public struct Foo: ProtocolA, ProtocolB {
>   func callBothFoos() {
> self.`ProtocolA.foo`()
> self.`ProtocolB.foo`()
>   }
> }
> 
> import A // extends Bar with bar()
> import B // also extends Bar with bar()
> 
> extension Bar {
>   func callBothBars() {
> self.`A.bar`()
> self.`B.bar`()
>   }
> }
> 

Like many others I am not a fan of the backticks being required in common use 
cases, but I don’t mind them in edge cases at all.  In those cases they are far 
better than no solution.  So +1 to using backticks to allow disambiguation!

> -Joe
> 
>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> Here’s a proposal draft to allow one to name any function in Swift. In 
>> effect, it’s continuing the discussion of retrieving getters and setters as 
>> functions started by Michael Henson here:
>> 
>>  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>  
>> 
>> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>  
>> 
>> 
>> Comments appreciated!
>> 
>> Generalized Naming for Any Function
>> 
>> Proposal: SE- 
>> 
>> 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, 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: Michael Henson started a thread about the 
>> getter/setter issue here 
>> ,
>>  continued here 
>> .
>>  See the Alternatives considered 
>> 
>>  section for commentary on that discussion.
>> 
>>  
>> 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, otherView)
>> }
>> which is painfully tedious. A similar workaround is required to produce a 
>> function value for a getter of a property, e.g.,
>> 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Félix Cloutier via swift-evolution]

Currently, they can be disambiguated using (self as ProtocolA).bar(), no?

Félix

> Le 29 déc. 2015 à 14:10:51, Erica Sadun via swift-evolution 
>  a écrit :
> 
> Talk about things you didn't know you needed until you see them. This is a 
> really nice way of disambiguating!
> 
> -- E
> 
>> On Dec 29, 2015, at 12:03 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Dec 29, 2015, at 10:17 AM, Joe Groff > > wrote:
>> 
>>> We also have a problem with disambiguating same-named members that come 
>>> from different extensions, whether via protocol extensions or independent 
>>> concrete extensions from different modules. Could we extend this scheme to 
>>> allow for disambiguating extension methods by protocol/module name?
>> 
>> That's a fantastic idea!
>> 
>>> 
>>> extension ProtocolA { func foo() }
>>> extension ProtocolB { func foo() }
>>> 
>>> public struct Foo: ProtocolA, ProtocolB {
>>>   func callBothFoos() {
>>> self.`ProtocolA.foo`()
>>> self.`ProtocolB.foo`()
>>>   }
>>> }
>>> 
>>> import A // extends Bar with bar()
>>> import B // also extends Bar with bar()
>>> 
>>> extension Bar {
>>>   func callBothBars() {
>>> self.`A.bar`()
>>> self.`B.bar`()
>>>   }
>>> }
>>> 
>>> -Joe
>>> 
 On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
 > wrote:
 
 Hi all,
 
 Here’s a proposal draft to allow one to name any function in Swift. In 
 effect, it’s continuing the discussion of retrieving getters and setters 
 as functions started by Michael Henson here:
 

 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
  
 
 
 the proposal follows, and is available here as well:
 

 https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
  
 
 
 Comments appreciated!
 
 Generalized Naming for Any Function
 
 Proposal: SE- 
 
 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, 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: Michael Henson started a thread about the 
 getter/setter issue here 
 ,
  continued here 
 .
  See the Alternatives considered 
 
  section for commentary on that discussion.
 
  
 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 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

>> On Dec 27, 2015, at 10:37 AM, Joe Groff  wrote:
>> 
>> 
>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Here’s a proposal draft to allow one to name any function in Swift. In 
>> effect, it’s continuing the discussion of retrieving getters and setters as 
>> functions started by Michael Henson here:
>> 
>>  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>> 
>> Comments appreciated!
>> 
>> Generalized Naming for Any Function
>> 
[snip]
> 
>> Getters and setters can be written using dotted syntax within the back-ticks:
>> 
>> let specificTitle = button.`currentTitle.get` // has type () -> String?
>> let otherTitle = UIButton.`currentTitle.get`  // has type (UIButton) -> () 
>> -> String?
>> let setTintColor = button.`tintColor.set` // has type (UIColor!) -> ()
>> The same syntax works with subscript getters and setters as well, using the 
>> full name of the subscript:
>> 
>> extension Matrix {
>>   subscript (row row: Int) -> [Double] {
>> get { ... }
>> set { ... }
>>   }
>> }
>> 
>> let getRow = someMatrix.`subscript(row:).get` // has type (Int) -> () -> 
>> [Double]
>> let setRow = someMatrix.`subscript(row:).set` // has type (Int) -> 
>> ([Double]) -> ()
> At least as far as pure Swift is concerned, for unapplied access, like 
> `UIButton.currentTitle`, I think it would be more consistent with the way 
> method references works for that to give you the getter (or lens) without 
> decoration. instance.instanceMethod has type Args -> Ret, and 
> Type.instanceMethod has type Self -> Args -> Ret; by analogy, since 
> instance.instanceProperty has type Ret or inout Ret, it's reasonable to 
> expect Type.instanceProperty to have type Self -> [inout] Ret.

Yes, that seems reasonable.

> Forming a getter or setter partially applied to an instance feels unmotivated 
> to me—{ button.currentTitle } or { button.currentTitle = $0 } already work, 
> and are arguably clearer than this syntax.

I’m not strongly motivated by it in and of itself; rather, I like the idea of 
being able to get at all of the functions (for completeness/consistency), 
partly because of the Objective-C selector issue.

> I acknowledge that this leaves forming selectors from setters out to dry, but 
> I feel like that's something that could be incorporated into a "lens" design 
> along with typed selectors. As a rough sketch, we could say that the 
> representation of @convention(selector) T -> inout U is a pair of 
> getter/setter selectors,

I should weigh in over on a typed-selectors thread, but my personal view is 
that typed selectors are a well-designed feature that isn't worth doing: one 
would probably not use them outside of interoperability with Objective-C. To 
make that work, we'd need a Clang feature as well (to express the types), then 
all of the relevant Objective-C APIs would need to adopt it for us to see the 
benefits. On iOS, we are talking about a relatively small number of APIs 
(100-ish), and many of those have blocks/closure-based variants that are 
preferred. 

> and provide API on Selector to grab the individual selectors from that, maybe 
> Selector(getterFor: UIView.currentTitle)/(setterFor: UIView.currentTitle)

Sure. I suspect that retrieving the selector of a getter/setter will be fairly 
rare, so I'm fine with that operation being ugly. 

> . I don't think get/set is a good interface for working with Swift 
> properties, so I don't like the idea of building in language support to 
> codify it beyond what's needed for ObjC interaction.

That is an excellent point. I think you've convinced me to drop the 
getter/setter part of this: lenses are the right abstraction for working with 
properties, and we can handle ObjC getter/setter in some other way. 

>> Can we drop the back-ticks? It's very tempting to want to drop the 
>> back-ticks entirely, because something like
>> 
>> let fn = someView.insertSubview(_:at:)
>> can be correctly parsed as a reference to insertSubview(_:at:). However, it 
>> breaks down at the margins, e.g., with getter/setter references or 
>> no-argument functions:
>> 
>> extension Optional {
>>   func get() -> T { return self! }
>> }
>> 
>> let fn1 = button.currentTitle.get   // getter or Optional.get?
>> let fn2 = set.removeAllElements()   // call or reference?
> From what I remember, the bigger concern with allowing foo(bar:bas:) without 
> backticks is parser error recovery. The unambiguity with call syntax depends 
> on having the `:)` token pair at the end. The edit distance between 
> foo(bar:bas:) and a call foo(bar: bas) or work-in-progress call foo(bar: x, 
> bas: ) is pretty slight, and would be tricky to give good diagnostics for. If 
> we felt 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Patrick Smith via swift-evolution]

Hi all, hope I’m not adding to what has already been said.
Instead of:
let fn = someView.insertSubview(_:at:)
Could you have:
let fn = someView.insertSubview(_ at: _)
Basically like unused parameters in reverse.
Filling out all parameters with _ would return a function to the method, like 
the behaviour proposed. The advantages would be consistency, readability, and 
compatibility with autocomplete.
Additionally this could possibly lead to partial parameter application, but 
that’s outside the scope of what is being discussed.
Patrick___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 29, 2015, at 11:03 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Dec 29, 2015, at 10:17 AM, Joe Groff  wrote:
>> 
>> We also have a problem with disambiguating same-named members that come from 
>> different extensions, whether via protocol extensions or independent 
>> concrete extensions from different modules. Could we extend this scheme to 
>> allow for disambiguating extension methods by protocol/module name?
> 
> That's a fantastic idea!

It does introduce some ambiguities at the margins. Given

  foo.`bar.get`()

Do we look for bar in the lexical scope or in the member scope of foo? Or both 
with yet another disambiguation mechanism?

I'm still traumatized by implementing the related C++ rules for

  foo.bar::get 

:)

This is the other thing that nudges me toward dropping getters/setters from the 
generalized naming proposal, because it leaves the use of '.' within backticks 
for your newly-proposed meaning. 
> 
>> 
>> extension ProtocolA { func foo() }
>> extension ProtocolB { func foo() }
>> 
>> public struct Foo: ProtocolA, ProtocolB {
>>   func callBothFoos() {
>> self.`ProtocolA.foo`()
>> self.`ProtocolB.foo`()
>>   }
>> }
>> 
>> import A // extends Bar with bar()
>> import B // also extends Bar with bar()
>> 
>> extension Bar {
>>   func callBothBars() {
>> self.`A.bar`()
>> self.`B.bar`()
>>   }
>> }
>> 
>> -Joe
>> 
>>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> Here’s a proposal draft to allow one to name any function in Swift. In 
>>> effect, it’s continuing the discussion of retrieving getters and setters as 
>>> functions started by Michael Henson here:
>>> 
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>> 
>>> the proposal follows, and is available here as well:
>>> 
>>> 
>>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>> 
>>> Comments appreciated!
>>> 
>>> Generalized Naming for Any Function
>>> Proposal: SE-
>>> 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, 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: Michael Henson started a thread about the 
>>> getter/setter issue here, continued here. See the Alternatives considered 
>>> section for commentary on that discussion.
>>> 
>>> 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, otherView)
>>> }
>>> which is painfully tedious. A similar workaround is required to produce a 
>>> function value for a getter of a property, e.g.,
>>> 
>>> extension UIButton {
>>>   var currentTitle: String? { ... }
>>> }
>>> 
>>> var fn: () -> String? = { () in
>>>   return button.currentTitle
>>> }
>>> 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 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 29, 2015, at 11:48 AM, Félix Cloutier  wrote:
> 
> Currently, they can be disambiguated using (self as ProtocolA).bar(), no?

Not if ProtocolA has self requirements or associated types. 
> 
> Félix
> 
>> Le 29 déc. 2015 à 14:10:51, Erica Sadun via swift-evolution 
>>  a écrit :
>> 
>> Talk about things you didn't know you needed until you see them. This is a 
>> really nice way of disambiguating!
>> 
>> -- E
>> 
>>> On Dec 29, 2015, at 12:03 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On Dec 29, 2015, at 10:17 AM, Joe Groff  wrote:
 
 We also have a problem with disambiguating same-named members that come 
 from different extensions, whether via protocol extensions or independent 
 concrete extensions from different modules. Could we extend this scheme to 
 allow for disambiguating extension methods by protocol/module name?
>>> 
>>> That's a fantastic idea!
>>> 
 
 extension ProtocolA { func foo() }
 extension ProtocolB { func foo() }
 
 public struct Foo: ProtocolA, ProtocolB {
   func callBothFoos() {
 self.`ProtocolA.foo`()
 self.`ProtocolB.foo`()
   }
 }
 
 import A // extends Bar with bar()
 import B // also extends Bar with bar()
 
 extension Bar {
   func callBothBars() {
 self.`A.bar`()
 self.`B.bar`()
   }
 }
 
 -Joe
 
> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a proposal draft to allow one to name any function in Swift. In 
> effect, it’s continuing the discussion of retrieving getters and setters 
> as functions started by Michael Henson here:
> 
>   
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
> 
> the proposal follows, and is available here as well:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
> 
> Comments appreciated!
> 
> Generalized Naming for Any Function
> 
> Proposal: SE-
> 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, 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: Michael Henson started a thread about the 
> getter/setter issue here, continued here. See the Alternatives considered 
> section for commentary on that discussion.
> 
> 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, otherView)
> }
> which is painfully tedious. A similar workaround is required to produce a 
> function value for a getter of a property, e.g.,
> 
> extension UIButton {
>   var currentTitle: String? { ... }
> }
> 
> var fn: () -> String? = { () in
>   return button.currentTitle
> }
> One additional bit of motivation: Swift should 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Félix Cloutier via swift-evolution]

Right.

Félix

> Le 29 déc. 2015 à 15:04:11, Douglas Gregor  a écrit :
> 
> 
> 
> Sent from my iPhone
> 
> On Dec 29, 2015, at 11:48 AM, Félix Cloutier  > wrote:
> 
>> Currently, they can be disambiguated using (self as ProtocolA).bar(), no?
> 
> Not if ProtocolA has self requirements or associated types. 
>> 
>> Félix
>> 
>>> Le 29 déc. 2015 à 14:10:51, Erica Sadun via swift-evolution 
>>> > a écrit :
>>> 
>>> Talk about things you didn't know you needed until you see them. This is a 
>>> really nice way of disambiguating!
>>> 
>>> -- E
>>> 
 On Dec 29, 2015, at 12:03 PM, Douglas Gregor via swift-evolution 
 > wrote:
 
 
 
 Sent from my iPhone
 
 On Dec 29, 2015, at 10:17 AM, Joe Groff > wrote:
 
> We also have a problem with disambiguating same-named members that come 
> from different extensions, whether via protocol extensions or independent 
> concrete extensions from different modules. Could we extend this scheme 
> to allow for disambiguating extension methods by protocol/module name?
 
 That's a fantastic idea!
 
> 
> extension ProtocolA { func foo() }
> extension ProtocolB { func foo() }
> 
> public struct Foo: ProtocolA, ProtocolB {
>   func callBothFoos() {
> self.`ProtocolA.foo`()
> self.`ProtocolB.foo`()
>   }
> }
> 
> import A // extends Bar with bar()
> import B // also extends Bar with bar()
> 
> extension Bar {
>   func callBothBars() {
> self.`A.bar`()
> self.`B.bar`()
>   }
> }
> 
> -Joe
> 
>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> Here’s a proposal draft to allow one to name any function in Swift. In 
>> effect, it’s continuing the discussion of retrieving getters and setters 
>> as functions started by Michael Henson here:
>> 
>>  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>  
>> 
>> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>  
>> 
>> 
>> Comments appreciated!
>> 
>> Generalized Naming for Any Function
>> 
>> Proposal: SE- 
>> 
>> 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, 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: Michael Henson started a thread about the 
>> getter/setter issue here 
>> ,
>>  continued here 
>> .
>>  See the Alternatives considered 
>> 
>>  section for commentary on that discussion.
>> 
>>  
>> 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 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[John McCall via swift-evolution]

> On Dec 28, 2015, at 1:14 PM, Joe Groff  wrote:
>> On Dec 28, 2015, at 1:09 PM, Brent Royal-Gordon  
>> wrote:
>> 
>>> and you could access the unapplied lens for an instance property using 
>>> `Type.property` syntax, analogous to how `Type.method` works. I feel like 
>>> if we did that, then it would obviate the need for explicit `property.get` 
>>> or `property.set` for most native Swift uses, though maybe not ObjC interop 
>>> uses.
>> 
>> I feel like if you don't have a way to fetch an unbound getter, you're 
>> missing the 90% case, which is constructs like:
>> 
>>  let textValues = textViews.map(.#text.get)
> 
> Agreed. I think there are a couple ways to approach that. We could resolve 
> unbound property references contextually, so that Type.property gives you the 
> getter in normal function context, or the lens in inout function context, 
> and/or either allow implicit upconversion from lens to getter function or 
> provide an explicit getter((inout T) -> inout U) -> T -> U adapter function.

So the contextual lookup rule would be:

If the expression
  .foo
or
  .foo(E…)
is known from context to yield a value of type T, then:
  if T is a nominal type, the expression is equivalent to T.foo(E…);
  if T is a function type (inout? U -> V), then the expression is equivalent to 
{ (x: inout? U) in x.foo(E…) };
  if T is a lens function type (inout? U -> inout V), then the argument 
expression (E…) shall not be present and the expression shall be equivalent to 
{ (x: inout? U) in  }, or whatever the “applied” lens syntax is;
otherwise the expression is ill-formed.

This would be an obstacle to allowing extension methods on a hypothetical 
Swift.Function type, but I think that’s an acceptable sacrifice.

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Brent Royal-Gordon via swift-evolution]

> Currently, they can be disambiguated using (self as ProtocolA).bar(), no?

I think this method is more about, for instance:

extension NSString {
func drawAtPoint(point: CGPoint, withAttributes attributes: 
[String: AnyObject]?) {
doSomeOtherThing()
myString.`UIKit.drawAtPoint`(point, withAttributes: 
attrs)
}
}

You use it to access a method by the module it comes from, not the protocol it 
comes from.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Brent Royal-Gordon via swift-evolution]

> and you could access the unapplied lens for an instance property using 
> `Type.property` syntax, analogous to how `Type.method` works. I feel like if 
> we did that, then it would obviate the need for explicit `property.get` or 
> `property.set` for most native Swift uses, though maybe not ObjC interop uses.

I feel like if you don't have a way to fetch an unbound getter, you're missing 
the 90% case, which is constructs like:

let textValues = textViews.map(.#text.get)

I do agree with you that the setter is usually far less useful—although the 
ReactiveCocoa people might not agree with us on that.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[T.J. Usiyan via swift-evolution]

Do things get any better if we combine the proposed changes and remove the
bare case? Begin function reference with some symbol (# here but it doesn't
matter), only use back tics to disambiguate keywords (which lines up with
their current use) and remove the unadorned case to avoid ambiguity.

```swift
class Foo {
func doSomething() { }
func doSomething(value: Int) { }
func sub
}

let fn = Foo#doSomething // no longer allowed
let fn = Foo#doSomething() // okay
let fn2 = Foo#doSomething(_:) // okay

// and

let getRow = someMatrix#`subscript`(row:).get

```



On Sun, Dec 27, 2015 at 10:40 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Given that someView.insertSubview(_:at:) can be correctly parsed, I would
> strongly lean towards the no-backtick alternative mentioned at the end. I
> feel as though the backticks end up looking very cluttered (particularly
> when you get into the double-nested backticks), and it seems cleaner to be
> able to reference a method as it was declared rather than having to add
> extra syntax.
>
> In reference to the issues noted with this approach:
>
> IMO, there is already enough syntactic difference between getters/setters
> and normal methods to justify requiring a different syntax to reference
> them. For instance, the # syntax could be used so that,
> button.currentTitle.get would reference Optional.get, and
> button.currentTitle#get would reference the getter. Or,
> button.`currentTitle.get` could reference the getter (i.e. backticks are
> only required in cases that are ambiguous).
>
> I also think it is reasonable to require that in the case of a method with
> no arguments such as set.removeAllElements, the programmer be expected to
> know the difference between the expression with and without the trailing
> parenthesis. After all, that distinction already exists in the language,
> and would not disappear with this proposed addition. If a parallel syntax
> for referencing methods with no arguments is strongly desired, perhaps
> something such as set.removeAllElements(:), set#removeAllElements(), or
> similar could be used, though I think that the present system for
> referencing these methods is sufficient.
>
> Are there other obvious reasons why this alternative wouldn’t work? I
> think it is the cleanest of the alternatives and avoids littering the code
> with backticks.
>
>
> Not having the back-ticks means that you will need to use contextual type
> information to disambiguate the zero-parameter case from other cases. For
> example:
>
> class Foo {
> func doSomething() { }
> func doSomething(value: Int) { }
> }
>
> let fn = Foo.doSomething // ambiguous
> let fn2 = Foo.doSomething(_:) // okay
> let fn3: (Foo) -> () -> Void = Foo.doSomething // okay
> let fn3: (Foo) -> (Int) -> Void = Foo.doSomething // okay
>
> My general complaint with the “drop the backticks” approach is that it
> doesn’t solve the whole problem. Sure, it solves 95% of the problem with a
> little less syntax, but now you need to invent yet another mechanism to
> handle the other cases (#set, contextual type disambiguation, etc)… which
> seems inconsistent to me.
>
> - Doug
>
>
> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> Here’s a proposal draft to allow one to name any function in Swift. In
> effect, it’s continuing the discussion of retrieving getters and setters as
> functions started by Michael Henson here:
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>
> the proposal follows, and is available here as well:
>
>
> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>
> Comments appreciated!
>
> Generalized Naming for Any Function
>
>- Proposal: SE-
>
> 
>- 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, 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: Michael Henson started a thread about the
> getter/setter issue here
> 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Stephen Celis via swift-evolution]

> On Dec 27, 2015, at 3:32 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Some more things to consider:
> 
> - Our naming conventions encourage the first parameter to most methods to be 
> unlabeled, so unlabeled parameters come up a lot. I don't think there's a 
> grammatical requirement for an identifier before each colon; maybe we can 
> leave out the underscore and use `foo(:bar:)` instead of `foo(_:bar:)` to 
> refer to unlabeled arguments.

Any reason not to put in a proposal to change this everywhere, e.g., 
diagnostics?

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Thorsten Seitz via swift-evolution]

Looks good so far.

Top-level functions:

#doSomething()
ModuleName#doSomething() // is it a problem to distinguish modules and classes 
here?

What about static/class functions? Any idea how to fit them into that scheme?

-Thorsten

> Am 28.12.2015 um 16:05 schrieb T.J. Usiyan via swift-evolution 
> :
> 
> Do things get any better if we combine the proposed changes and remove the 
> bare case? Begin function reference with some symbol (# here but it doesn't 
> matter), only use back tics to disambiguate keywords (which lines up with 
> their current use) and remove the unadorned case to avoid ambiguity.
> 
> ```swift 
> class Foo {
>   func doSomething() { }
>   func doSomething(value: Int) { }
>   func sub
> }
> 
> let fn = Foo#doSomething // no longer allowed
> let fn = Foo#doSomething() // okay
> let fn2 = Foo#doSomething(_:) // okay
> 
> // and
> 
> let getRow = someMatrix#`subscript`(row:).get
> 
> ```
> 
> 
> 
>> On Sun, Dec 27, 2015 at 10:40 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>>> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution 
>>>  wrote:
>>> 
>>> Given that someView.insertSubview(_:at:) can be correctly parsed, I would 
>>> strongly lean towards the no-backtick alternative mentioned at the end. I 
>>> feel as though the backticks end up looking very cluttered (particularly 
>>> when you get into the double-nested backticks), and it seems cleaner to be 
>>> able to reference a method as it was declared rather than having to add 
>>> extra syntax.
>>> 
>>> In reference to the issues noted with this approach:
>>> 
>>> IMO, there is already enough syntactic difference between getters/setters 
>>> and normal methods to justify requiring a different syntax to reference 
>>> them. For instance, the # syntax could be used so that, 
>>> button.currentTitle.get would reference Optional.get, and 
>>> button.currentTitle#get would reference the getter. Or, 
>>> button.`currentTitle.get` could reference the getter (i.e. backticks are 
>>> only required in cases that are ambiguous).
>>> 
>>> I also think it is reasonable to require that in the case of a method with 
>>> no arguments such as set.removeAllElements, the programmer be expected to 
>>> know the difference between the expression with and without the trailing 
>>> parenthesis. After all, that distinction already exists in the language, 
>>> and would not disappear with this proposed addition. If a parallel syntax 
>>> for referencing methods with no arguments is strongly desired, perhaps 
>>> something such as set.removeAllElements(:), set#removeAllElements(), or 
>>> similar could be used, though I think that the present system for 
>>> referencing these methods is sufficient.
>>> 
>>> Are there other obvious reasons why this alternative wouldn’t work? I think 
>>> it is the cleanest of the alternatives and avoids littering the code with 
>>> backticks.
>> 
>> Not having the back-ticks means that you will need to use contextual type 
>> information to disambiguate the zero-parameter case from other cases. For 
>> example:
>> 
>>  class Foo {
>>  func doSomething() { }
>>  func doSomething(value: Int) { }
>>  }
>> 
>>  let fn = Foo.doSomething // ambiguous
>>  let fn2 = Foo.doSomething(_:) // okay
>>  let fn3: (Foo) -> () -> Void = Foo.doSomething // okay
>>  let fn3: (Foo) -> (Int) -> Void = Foo.doSomething // okay
>> 
>> My general complaint with the “drop the backticks” approach is that it 
>> doesn’t solve the whole problem. Sure, it solves 95% of the problem with a 
>> little less syntax, but now you need to invent yet another mechanism to 
>> handle the other cases (#set, contextual type disambiguation, etc)… which 
>> seems inconsistent to me.
>> 
>>  - Doug
>> 
>> 
 On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
  wrote:
 
 Hi all,
 
 Here’s a proposal draft to allow one to name any function in Swift. In 
 effect, it’s continuing the discussion of retrieving getters and setters 
 as functions started by Michael Henson here:
 

 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
 
 the proposal follows, and is available here as well:
 

 https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
 
 Comments appreciated!
 
 Generalized Naming for Any Function
 
 Proposal: SE-
 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, it is 
 not possible to specifically name every function that is part of a Swift 
 program---one 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Stephen Celis via swift-evolution]

> On Dec 28, 2015, at 11:47 AM, Alex Migicovsky via swift-evolution 
>  wrote:
>> On Dec 27, 2015, at 1:32 PM, Joe Groff via swift-evolution 
>> > wrote:
>> 
>> Some more things to consider:
>> 
>> - Our naming conventions encourage the first parameter to most methods to be 
>> unlabeled, so unlabeled parameters come up a lot. I don't think there's a 
>> grammatical requirement for an identifier before each colon; maybe we can 
>> leave out the underscore and use `foo(:bar:)` instead of `foo(_:bar:)` to 
>> refer to unlabeled arguments.
> 
> At first glance it seems like we can remove the parens altogether if we went 
> with this approach. Could instance.`foo:bar:` work (instance.`foo` in the 
> no-arg case)? I’m not sure how removing parens would work for inits and 
> subscripts though.

While the conventions encourage the first parameter to be unlabeled, it doesn't 
enforce it (and there are exceptions in the standard library, like 
`removeAll(keepCapacity:)`, as well as `stride(to:…)` and `stride(through:…)`.

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Alex Migicovsky via swift-evolution]

> On Dec 28, 2015, at 10:24 AM, Stephen Celis  wrote:
> 
>> On Dec 28, 2015, at 11:47 AM, Alex Migicovsky via swift-evolution 
>> > wrote:
>>> On Dec 27, 2015, at 1:32 PM, Joe Groff via swift-evolution 
>>> > wrote:
>>> 
>>> Some more things to consider:
>>> 
>>> - Our naming conventions encourage the first parameter to most methods to 
>>> be unlabeled, so unlabeled parameters come up a lot. I don't think there's 
>>> a grammatical requirement for an identifier before each colon; maybe we can 
>>> leave out the underscore and use `foo(:bar:)` instead of `foo(_:bar:)` to 
>>> refer to unlabeled arguments.
>> 
>> At first glance it seems like we can remove the parens altogether if we went 
>> with this approach. Could instance.`foo:bar:` work (instance.`foo` in the 
>> no-arg case)? I’m not sure how removing parens would work for inits and 
>> subscripts though.
> 
> While the conventions encourage the first parameter to be unlabeled, it 
> doesn't enforce it (and there are exceptions in the standard library, like 
> `removeAll(keepCapacity:)`, as well as `stride(to:…)` and `stride(through:…)`.
> 
> Stephen

Ah right, great point :-)

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Joe Groff via swift-evolution]

> On Dec 27, 2015, at 2:47 PM, John McCall  wrote:
> 
>> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution 
>> > wrote:
>>> Getters and setters can be written using dotted syntax within the 
>>> back-ticks:
>>> 
>>> let specificTitle = button.`currentTitle.get` // has type () -> String?
>>> let otherTitle = UIButton.`currentTitle.get`  // has type (UIButton) -> () 
>>> -> String?
>>> let setTintColor = button.`tintColor.set` // has type (UIColor!) -> ()
>>> The same syntax works with subscript getters and setters as well, using the 
>>> full name of the subscript:
>>> 
>>> extension Matrix {
>>>   subscript (row row: Int) -> [Double] {
>>> get { ... }
>>> set { ... }
>>>   }
>>> }
>>> 
>>> let getRow = someMatrix.`subscript(row:).get` // has type (Int) -> () -> 
>>> [Double]
>>> let setRow = someMatrix.`subscript(row:).set` // has type (Int) -> 
>>> ([Double]) -> ()
>> At least as far as pure Swift is concerned, for unapplied access, like 
>> `UIButton.currentTitle`, I think it would be more consistent with the way 
>> method references works for that to give you the getter (or lens) without 
>> decoration. instance.instanceMethod has type Args -> Ret, and 
>> Type.instanceMethod has type Self -> Args -> Ret; by analogy, since 
>> instance.instanceProperty has type Ret or inout Ret, it's reasonable to 
>> expect Type.instanceProperty to have type Self -> [inout] Ret. Forming a 
>> getter or setter partially applied to an instance feels unmotivated to me—{ 
>> button.currentTitle } or { button.currentTitle = $0 } already work, and are 
>> arguably clearer than this syntax.
>> 
>> I acknowledge that this leaves forming selectors from setters out to dry, 
>> but I feel like that's something that could be incorporated into a "lens" 
>> design along with typed selectors. As a rough sketch, we could say that the 
>> representation of @convention(selector) T -> inout U is a pair of 
>> getter/setter selectors, and provide API on Selector to grab the individual 
>> selectors from that, maybe Selector(getterFor: 
>> UIView.currentTitle)/(setterFor: UIView.currentTitle). I don't think get/set 
>> is a good interface for working with Swift properties, so I don't like the 
>> idea of building in language support to codify it beyond what's needed for 
>> ObjC interaction.
> 
> I know this might be too early, but: what syntax are we thinking of for 
> lenses?  We might want to design this with future consistency in mind.

Vaguely, I think it could look something like this. You could define a lens 
function by having it return `inout`. Calling the function produces an lvalue 
whose access nests within the accesses of its input `inout` parameters, if any, 
allowing for things like:

var localVar = 1
let localRef: () -> inout Int = {  }

func second(inout array: [Int]) -> inout Int {
  return [1]
}

// Maybe you can define an inout function with accessors too
func fahrenheit(inout celsius: Double) -> inout Double {
  get {
return celsius * 9/5 + 32
  }
  set {
celsius = (newValue - 32) * 5/9
  }
}

and you could access the unapplied lens for an instance property using 
`Type.property` syntax, analogous to how `Type.method` works. I feel like if we 
did that, then it would obviate the need for explicit `property.get` or 
`property.set` for most native Swift uses, though maybe not ObjC interop uses.

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Wallacy via swift-evolution]

And if we only make the actual type inference more powerful?

Using the examples on proposal:

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



let fn1: (UIView, Int) = someView.insertSubview// ok: uses
insertSubview(_:at:)let fn2: (UIView, aboveSubview: UIView) =
someView.insertSubview // Ok: no more ambiguous!let fn3: (UIView,
belowSubview: UIView) = someView.insertSubview // Ok: no more
ambiguous!


And for properties:

let specificTitle:() -> String? = button.currentTitle // will pick the
getterlet otherTitle: (UIButton) -> () -> String? =
UIButton.currentTitle  // will pick the getterlet setTintColor:
(UIColor!) -> () = button.tintColor // will pick the setter


This can be an opportunity to do something like that:

func processColor(data: Any, delegate : (UIColor!) -> ())

processColor(someData, button.tintColor) // will pass tintColor setter


And for subscript:

extension Matrix {
  subscript (row row: Int) -> [Double] {
get { ... }
set { ... }
  }
}
let getRow: (Int) -> () -> [Double] = someMatrix // will pick the
subscript getterlet setRow: (Int) -> ([Double]) -> () = someMatrix //
will pick the subscript setter



Of course is more hard, but there's no new notation, just a expansion of
the current type inference.

Maybe some syntax sugar can be provided in another proposal, but this one
can be the kickoff.


Em seg, 28 de dez de 2015 às 16:10, Joe Groff via swift-evolution <
swift-evolution@swift.org> escreveu:

>
> On Dec 27, 2015, at 2:47 PM, John McCall  wrote:
>
> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>-
>
>Getters and setters can be written using dotted syntax within the
>back-ticks:
>
>let specificTitle = button.`currentTitle.get` // has type () -> String?let 
> otherTitle = UIButton.`currentTitle.get`  // has type (UIButton) -> () -> 
> String?let setTintColor = button.`tintColor.set` // has type (UIColor!) 
> -> ()
>
>The same syntax works with subscript getters and setters as well,
>using the full name of the subscript:
>
>extension Matrix {
>  subscript (row row: Int) -> [Double] {
>get { ... }
>set { ... }
>  }
>}
>let getRow = someMatrix.`subscript(row:).get` // has type (Int) -> () -> 
> [Double]let setRow = someMatrix.`subscript(row:).set` // has type (Int) -> 
> ([Double]) -> ()
>
>
> At least as far as pure Swift is concerned, for unapplied access, like
> `UIButton.currentTitle`, I think it would be more consistent with the way
> method references works for that to give you the getter (or lens) without
> decoration. instance.instanceMethod has type Args -> Ret, and
> Type.instanceMethod has type Self -> Args -> Ret; by analogy, since
> instance.instanceProperty has type Ret or inout Ret, it's reasonable to
> expect Type.instanceProperty to have type Self -> [inout] Ret. Forming a
> getter or setter partially applied to an instance feels unmotivated to me—{
> button.currentTitle } or { button.currentTitle = $0 } already work, and are
> arguably clearer than this syntax.
>
> I acknowledge that this leaves forming selectors from setters out to dry,
> but I feel like that's something that could be incorporated into a "lens"
> design along with typed selectors. As a rough sketch, we could say that the
> representation of @convention(selector) T -> inout U is a pair of
> getter/setter selectors, and provide API on Selector to grab the individual
> selectors from that, maybe Selector(getterFor:
> UIView.currentTitle)/(setterFor: UIView.currentTitle). I don't think
> get/set is a good interface for working with Swift properties, so I don't
> like the idea of building in language support to codify it beyond what's
> needed for ObjC interaction.
>
>
> I know this might be too early, but: what syntax are we thinking of for
> lenses?  We might want to design this with future consistency in mind.
>
>
> Vaguely, I think it could look something like this. You could define a
> lens function by having it return `inout`. Calling the function produces an
> lvalue whose access nests within the accesses of its input `inout`
> parameters, if any, allowing for things like:
>
> var localVar = 1
> let localRef: () -> inout Int = {  }
>
> func second(inout array: [Int]) -> inout Int {
>   return [1]
> }
>
> // Maybe you can define an inout function with accessors too
> func fahrenheit(inout celsius: Double) -> inout Double {
>   get {
> return celsius * 9/5 + 32
>   }
>   set {
> celsius = (newValue - 32) * 5/9
>   }
> }
>
>
> and you could access the unapplied lens for an instance property using
> `Type.property` syntax, analogous to how `Type.method` works. I feel like
> if we did that, then it would obviate the need for explicit `property.get`
> or `property.set` for 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 27, 2015, at 8:34 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 27, 2015, at 4:27 PM, John McCall  wrote:
>>> 
>>> On Dec 27, 2015, at 4:15 PM, Chris Lattner  wrote:
>>> 
>>> On Dec 27, 2015, at 4:09 PM, John McCall  wrote:
> I’m a fan of good error recovery, but I don’t think it is a major concern 
> here for two reasons:
> 
> 1) The most common case in a method will lack a label, and "thing.foo(_: 
> “ and “thing.foo(:” are both unambiguously a curried reference.
> 2) A common case of accidentally completing a nullary call (thing.foo() 
> vs thing.foo) will produce a type error.  We already produce good QoI for 
> an unapplied function - adding the inverse would be simple.
> 
> Further, it will be uncommon *in general* to form a curried reference, so 
> error recovery doesn’t have to be perfect in all the edge cases.  As with 
> other commenters, if it is at all possible to avoid the extra backticks, 
> I’d really prefer that.
 
 The concern, I think, is that a messed-up normal call might look like a 
 curried reference.
 
 My inclination would be to go the other way: if we get a syntax for this 
 that we like, I think we should use it for *all* curried member 
 references, and reject things like foo.bar in favor of foo.`bar`.  The 
 ability to write foo.bar for a method has always struck me as more clever 
 than wise, to be honest.
>>> 
>>> If you were to go that far, I’d suggest looking at this as a different 
>>> version of the “." operator.  If you resyntax curried to something else 
>>> like (just a strawman, intentionally ugly syntax):
>>> 
>>>foo.#bar
>>> 
>>> Then you’d get a nice property that the plain old dot operator always has 
>>> to be fully applied.  This certainly would be a win for error recovery.  
>>> Also, if you did this, you wouldn’t need the backticks from doug’s proposal 
>>> either for things like:
>>> 
>>>foo.#bar(param1:param2:)
>>> 
>>> either.
>> 
>> Right.  I really like this effect.
>> 
>> I’m not that bothered by requiring the backticks, especially because it 
>> generalizes well to non-member function references, which I’m not sure any 
>> sort of different-member-access syntax does.
> 
> I’m bothered by it because it overloads backtick to mean two things: 
> keywords-as-names, and annoying-sequences-of-tokens-as-names.  Either use 
> would be acceptable to me, but the fact that we have to support one nested 
> inside the other makes it pretty nasty.

In the context of this proposal, I think of backticks as delimiters around a 
generalized name. It's a generalization of today's notion that it's an escaped 
identifier; more like an escaped name. 

> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[David Waite via swift-evolution]

Does this bridge over to referencing properties, such as using:

struct Bar {
   var counter:Int = 0
}

let fn3 = Bar#counter.get

-DW


> On Dec 28, 2015, at 8:05 AM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> Do things get any better if we combine the proposed changes and remove the 
> bare case? Begin function reference with some symbol (# here but it doesn't 
> matter), only use back tics to disambiguate keywords (which lines up with 
> their current use) and remove the unadorned case to avoid ambiguity.
> 
> ```swift 
> class Foo {
>   func doSomething() { }
>   func doSomething(value: Int) { }
>   func sub
> }
> 
> let fn = Foo#doSomething // no longer allowed
> let fn = Foo#doSomething() // okay
> let fn2 = Foo#doSomething(_:) // okay
> 
> // and
> 
> let getRow = someMatrix#`subscript`(row:).get
> 
> ```
> 
> 
> 
> On Sun, Dec 27, 2015 at 10:40 PM, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution 
>> > wrote:
>> 
>> Given that someView.insertSubview(_:at:) can be correctly parsed, I would 
>> strongly lean towards the no-backtick alternative mentioned at the end. I 
>> feel as though the backticks end up looking very cluttered (particularly 
>> when you get into the double-nested backticks), and it seems cleaner to be 
>> able to reference a method as it was declared rather than having to add 
>> extra syntax.
>> 
>> In reference to the issues noted with this approach:
>> 
>> IMO, there is already enough syntactic difference between getters/setters 
>> and normal methods to justify requiring a different syntax to reference 
>> them. For instance, the # syntax could be used so that, 
>> button.currentTitle.get would reference Optional.get, and 
>> button.currentTitle#get would reference the getter. Or, 
>> button.`currentTitle.get` could reference the getter (i.e. backticks are 
>> only required in cases that are ambiguous).
>> 
>> I also think it is reasonable to require that in the case of a method with 
>> no arguments such as set.removeAllElements, the programmer be expected to 
>> know the difference between the expression with and without the trailing 
>> parenthesis. After all, that distinction already exists in the language, and 
>> would not disappear with this proposed addition. If a parallel syntax for 
>> referencing methods with no arguments is strongly desired, perhaps something 
>> such as set.removeAllElements(:), set#removeAllElements(), or similar could 
>> be used, though I think that the present system for referencing these 
>> methods is sufficient.
>> 
>> Are there other obvious reasons why this alternative wouldn’t work? I think 
>> it is the cleanest of the alternatives and avoids littering the code with 
>> backticks.
> 
> Not having the back-ticks means that you will need to use contextual type 
> information to disambiguate the zero-parameter case from other cases. For 
> example:
> 
>   class Foo {
>   func doSomething() { }
>   func doSomething(value: Int) { }
>   }
> 
>   let fn = Foo.doSomething // ambiguous
>   let fn2 = Foo.doSomething(_:) // okay
>   let fn3: (Foo) -> () -> Void = Foo.doSomething // okay
>   let fn3: (Foo) -> (Int) -> Void = Foo.doSomething // okay
> 
> My general complaint with the “drop the backticks” approach is that it 
> doesn’t solve the whole problem. Sure, it solves 95% of the problem with a 
> little less syntax, but now you need to invent yet another mechanism to 
> handle the other cases (#set, contextual type disambiguation, etc)… which 
> seems inconsistent to me.
> 
>   - Doug
> 
> 
>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>>> Hi all,
>>> 
>>> Here’s a proposal draft to allow one to name any function in Swift. In 
>>> effect, it’s continuing the discussion of retrieving getters and setters as 
>>> functions started by Michael Henson here:
>>> 
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>>  
>>> 
>>> 
>>> the proposal follows, and is available here as well:
>>> 
>>> 
>>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>>  
>>> 
>>> 
>>> Comments appreciated!
>>> 
>>> Generalized Naming for Any Function
>>> 
>>> Proposal: SE- 
>>> 
>>> Author(s): Doug Gregor 
>>> Status: Awaiting Review
>>> Review manager: TBD
>>>  

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Wallacy via swift-evolution]

"In the context of this proposal, I think of backticks as delimiters around
a generalized name. It's a generalization of today's notion that it's an
escaped identifier; more like an escaped name."

backticks are just a "hack", with the proposal 0001 (Allow (most) keywords
as argument labels),  your proposal, we just will not see this feature
being used.

It's not just a matter of style, just does not seem natural.

Expand type annotation to "pick" the correct function, as I said before,
seems to me more natural. Or choose another symbol of course.

Em seg, 28 de dez de 2015 às 17:49, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> escreveu:

>
>
> Sent from my iPhone
>
> > On Dec 27, 2015, at 8:34 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >>> On Dec 27, 2015, at 4:27 PM, John McCall  wrote:
> >>>
> >>> On Dec 27, 2015, at 4:15 PM, Chris Lattner  wrote:
> >>>
> >>> On Dec 27, 2015, at 4:09 PM, John McCall  wrote:
> > I’m a fan of good error recovery, but I don’t think it is a major
> concern here for two reasons:
> >
> > 1) The most common case in a method will lack a label, and
> "thing.foo(_: “ and “thing.foo(:” are both unambiguously a curried
> reference.
> > 2) A common case of accidentally completing a nullary call
> (thing.foo() vs thing.foo) will produce a type error.  We already produce
> good QoI for an unapplied function - adding the inverse would be simple.
> >
> > Further, it will be uncommon *in general* to form a curried
> reference, so error recovery doesn’t have to be perfect in all the edge
> cases.  As with other commenters, if it is at all possible to avoid the
> extra backticks, I’d really prefer that.
> 
>  The concern, I think, is that a messed-up normal call might look like
> a curried reference.
> 
>  My inclination would be to go the other way: if we get a syntax for
> this that we like, I think we should use it for *all* curried member
> references, and reject things like foo.bar in favor of foo.`bar`.  The
> ability to write foo.bar for a method has always struck me as more clever
> than wise, to be honest.
> >>>
> >>> If you were to go that far, I’d suggest looking at this as a different
> version of the “." operator.  If you resyntax curried to something else
> like (just a strawman, intentionally ugly syntax):
> >>>
> >>>foo.#bar
> >>>
> >>> Then you’d get a nice property that the plain old dot operator always
> has to be fully applied.  This certainly would be a win for error
> recovery.  Also, if you did this, you wouldn’t need the backticks from
> doug’s proposal either for things like:
> >>>
> >>>foo.#bar(param1:param2:)
> >>>
> >>> either.
> >>
> >> Right.  I really like this effect.
> >>
> >> I’m not that bothered by requiring the backticks, especially because it
> generalizes well to non-member function references, which I’m not sure any
> sort of different-member-access syntax does.
> >
> > I’m bothered by it because it overloads backtick to mean two things:
> keywords-as-names, and annoying-sequences-of-tokens-as-names.  Either use
> would be acceptable to me, but the fact that we have to support one nested
> inside the other makes it pretty nasty.
>
> In the context of this proposal, I think of backticks as delimiters around
> a generalized name. It's a generalization of today's notion that it's an
> escaped identifier; more like an escaped name.
>
> > -Chris
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Frederick Kellison-Linn via swift-evolution]

Given that someView.insertSubview(_:at:) can be correctly parsed, I would 
strongly lean towards the no-backtick alternative mentioned at the end. I feel 
as though the backticks end up looking very cluttered (particularly when you 
get into the double-nested backticks), and it seems cleaner to be able to 
reference a method as it was declared rather than having to add extra syntax.

In reference to the issues noted with this approach:

IMO, there is already enough syntactic difference between getters/setters and 
normal methods to justify requiring a different syntax to reference them. For 
instance, the # syntax could be used so that, button.currentTitle.get would 
reference Optional.get, and button.currentTitle#get would reference the 
getter. Or, button.`currentTitle.get` could reference the getter (i.e. 
backticks are only required in cases that are ambiguous).

I also think it is reasonable to require that in the case of a method with no 
arguments such as set.removeAllElements, the programmer be expected to know the 
difference between the expression with and without the trailing parenthesis. 
After all, that distinction already exists in the language, and would not 
disappear with this proposed addition. If a parallel syntax for referencing 
methods with no arguments is strongly desired, perhaps something such as 
set.removeAllElements(:), set#removeAllElements(), or similar could be used, 
though I think that the present system for referencing these methods is 
sufficient.

Are there other obvious reasons why this alternative wouldn’t work? I think it 
is the cleanest of the alternatives and avoids littering the code with 
backticks.

FKL

On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
> wrote:

> Hi all,
> 
> Here’s a proposal draft to allow one to name any function in Swift. In 
> effect, it’s continuing the discussion of retrieving getters and setters as 
> functions started by Michael Henson here:
> 
>   
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>  
> 
> 
> the proposal follows, and is available here as well:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>  
> 
> 
> Comments appreciated!
> 
> Generalized Naming for Any Function
> 
> Proposal: SE- 
> 
> 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, 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: Michael Henson started a thread about the 
> getter/setter issue here 
> ,
>  continued here 
> .
>  See the Alternatives considered 
> 
>  section for commentary on that discussion.
> 
>  
> 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 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Nicky Gerritsen via swift-evolution]

I have to agree with Frederick that the two-backticks example looks horrible 
;-). I guess the # way worjs better in that case.

I’m not entirely sure about his second remark: if we require that references to 
functions without arguments are written without parenthesis, don’t we then have 
some inconsistency? i.e. functions without arguments are obj.func while 
functions with arguments are obj.func(_:y:). I’m not really in favor of this 
inconsistency. But I’m not really sure currently how we can easily solve this 
without creating more strange inconsistencies...

Regards,

Nicky

> On 27 dec. 2015, at 09:27, Frederick Kellison-Linn via swift-evolution 
>  wrote:
> 
> Given that someView.insertSubview(_:at:) can be correctly parsed, I would 
> strongly lean towards the no-backtick alternative mentioned at the end. I 
> feel as though the backticks end up looking very cluttered (particularly when 
> you get into the double-nested backticks), and it seems cleaner to be able to 
> reference a method as it was declared rather than having to add extra syntax.
> 
> In reference to the issues noted with this approach:
> 
> IMO, there is already enough syntactic difference between getters/setters and 
> normal methods to justify requiring a different syntax to reference them. For 
> instance, the # syntax could be used so that, button.currentTitle.get would 
> reference Optional.get, and button.currentTitle#get would reference 
> the getter. Or, button.`currentTitle.get` could reference the getter (i.e. 
> backticks are only required in cases that are ambiguous).
> 
> I also think it is reasonable to require that in the case of a method with no 
> arguments such as set.removeAllElements, the programmer be expected to know 
> the difference between the expression with and without the trailing 
> parenthesis. After all, that distinction already exists in the language, and 
> would not disappear with this proposed addition. If a parallel syntax for 
> referencing methods with no arguments is strongly desired, perhaps something 
> such as set.removeAllElements(:), set#removeAllElements(), or similar could 
> be used, though I think that the present system for referencing these methods 
> is sufficient.
> 
> Are there other obvious reasons why this alternative wouldn’t work? I think 
> it is the cleanest of the alternatives and avoids littering the code with 
> backticks.
> 
> FKL
> 
> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> Hi all,
>> 
>> Here’s a proposal draft to allow one to name any function in Swift. In 
>> effect, it’s continuing the discussion of retrieving getters and setters as 
>> functions started by Michael Henson here:
>> 
>>  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>  
>> 
>> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>  
>> 
>> 
>> Comments appreciated!
>> 
>> Generalized Naming for Any Function
>> 
>> Proposal: SE- 
>> 
>> 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, 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: Michael Henson started a thread about the 
>> getter/setter issue here 
>> ,
>>  continued here 
>> .
>>  See the Alternatives considered 
>> 
>>  section for commentary on that discussion.
>> 
>>  
>> Motivation
>> 
>> It's fairly common in Swift for multiple functions or methods to have the 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Joe Groff via swift-evolution]

Some more things to consider:

- Our naming conventions encourage the first parameter to most methods to be 
unlabeled, so unlabeled parameters come up a lot. I don't think there's a 
grammatical requirement for an identifier before each colon; maybe we can leave 
out the underscore and use `foo(:bar:)` instead of `foo(_:bar:)` to refer to 
unlabeled arguments.

- How do labeled references interact with default and variadic arguments? If 
you have a func foo(x: Int = 0, y: String = 0), can you refer to foo(x:) and 
foo(y:) to apply some of the defaulted arguments, or only foo(x:y:)? Would 
foo(y:x:) also work?

-Joe

> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> Here’s a proposal draft to allow one to name any function in Swift. In 
>> effect, it’s continuing the discussion of retrieving getters and setters as 
>> functions started by Michael Henson here:
>> 
>>  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>  
>> 
>> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>  
>> 
>> 
>> Comments appreciated!
>> 
>> Generalized Naming for Any Function
>> 
>> Proposal: SE- 
>> 
>> 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, 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: Michael Henson started a thread about the 
>> getter/setter issue here 
>> ,
>>  continued here 
>> .
>>  See the Alternatives considered 
>> 
>>  section for commentary on that discussion.
>> 
>>  
>> 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, otherView)
>> }
>> which is painfully tedious. A similar workaround is required to produce a 
>> function value for a getter of a property, e.g.,
>> 
>> extension UIButton {
>>   var currentTitle: String? { ... }
>> }
>> 
>> var fn: () -> String? = { () in
>>   return button.currentTitle
>> }
>> 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). 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Joe Groff via swift-evolution]

> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a proposal draft to allow one to name any function in Swift. In 
> effect, it’s continuing the discussion of retrieving getters and setters as 
> functions started by Michael Henson here:
> 
>   
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>  
> 
> 
> the proposal follows, and is available here as well:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>  
> 
> 
> Comments appreciated!
> 
> Generalized Naming for Any Function
> 
> Proposal: SE- 
> 
> 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, 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: Michael Henson started a thread about the 
> getter/setter issue here 
> ,
>  continued here 
> .
>  See the Alternatives considered 
> 
>  section for commentary on that discussion.
> 
>  
> 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, otherView)
> }
> which is painfully tedious. A similar workaround is required to produce a 
> function value for a getter of a property, e.g.,
> 
> extension UIButton {
>   var currentTitle: String? { ... }
> }
> 
> var fn: () -> String? = { () in
>   return button.currentTitle
> }
> 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
> 
> Swift currently has a back-tick escaping syntax that lets one use keywords 
> for names, which would otherwise fail to parse. For example,
> 
> func `try`() -> Bool { ... }
> declares a function named try, even though try is a keyword. I propose to 
> extend the back-tick syntax to allow compound Swift names (e.g., 
> insertSubview(_:aboveSubview:)) and references to the accessors of properties 
> (e.g., the getter for currentTitle). Specifically,
> 
> Compound names can be written entirely within the back-ticks, e.g.,
> 
> 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Chris Lattner via swift-evolution]

On Dec 27, 2015, at 4:09 PM, John McCall  wrote:
>> I’m a fan of good error recovery, but I don’t think it is a major concern 
>> here for two reasons:
>> 
>> 1) The most common case in a method will lack a label, and "thing.foo(_: “ 
>> and “thing.foo(:” are both unambiguously a curried reference.
>> 2) A common case of accidentally completing a nullary call (thing.foo() vs 
>> thing.foo) will produce a type error.  We already produce good QoI for an 
>> unapplied function - adding the inverse would be simple.
>> 
>> Further, it will be uncommon *in general* to form a curried reference, so 
>> error recovery doesn’t have to be perfect in all the edge cases.  As with 
>> other commenters, if it is at all possible to avoid the extra backticks, I’d 
>> really prefer that.
> 
> The concern, I think, is that a messed-up normal call might look like a 
> curried reference.
> 
> My inclination would be to go the other way: if we get a syntax for this that 
> we like, I think we should use it for *all* curried member references, and 
> reject things like foo.bar in favor of foo.`bar`.  The ability to write 
> foo.bar for a method has always struck me as more clever than wise, to be 
> honest.

If you were to go that far, I’d suggest looking at this as a different version 
of the “." operator.  If you resyntax curried to something else like (just a 
strawman, intentionally ugly syntax):

foo.#bar

Then you’d get a nice property that the plain old dot operator always has to be 
fully applied.  This certainly would be a win for error recovery.  Also, if you 
did this, you wouldn’t need the backticks from doug’s proposal either for 
things like:

foo.#bar(param1:param2:)

either.

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Chris Lattner via swift-evolution]

On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution 
 wrote:
>> can be correctly parsed as a reference to insertSubview(_:at:). However, it 
>> breaks down at the margins, e.g., with getter/setter references or 
>> no-argument functions:
>> 
>> extension Optional {
>>   func get() -> T { return self! }
>> }
>> 
>> let fn1 = button.currentTitle.get   // getter or Optional.get?
>> let fn2 = set.removeAllElements()   // call or reference?
> From what I remember, the bigger concern with allowing foo(bar:bas:) without 
> backticks is parser error recovery. The unambiguity with call syntax depends 
> on having the `:)` token pair at the end. The edit distance between 
> foo(bar:bas:) and a call foo(bar: bas) or work-in-progress call foo(bar: x, 
> bas: ) is pretty slight, and would be tricky to give good diagnostics for. If 
> we felt confident we could give good diagnostics, I'd support removing the 
> backticks.

I’m a fan of good error recovery, but I don’t think it is a major concern here 
for two reasons:

1) The most common case in a method will lack a label, and "thing.foo(_: “ and 
“thing.foo(:” are both unambiguously a curried reference.
2) A common case of accidentally completing a nullary call (thing.foo() vs 
thing.foo) will produce a type error.  We already produce good QoI for an 
unapplied function - adding the inverse would be simple.

Further, it will be uncommon *in general* to form a curried reference, so error 
recovery doesn’t have to be perfect in all the edge cases.  As with other 
commenters, if it is at all possible to avoid the extra backticks, I’d really 
prefer that.

-Chris

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Michel Fortin via swift-evolution]

Le 27 déc. 2015 à 19:54, Wallacy via swift-evolution 
 a écrit :
> Even with backticks would not be possible.
> 
> You may need to reference the method signature altogether.
> 
> var someA = A()
> let fn1 = someA.#someFunc(a: Int) -> Int
> let fn2 = someA.#someFunc(a: Int) -> Double 
> let fn3 = someA.#someFunc(a: Double) -> Int 
> let fn4 = someA.#someFunc(a: Double) -> Double
> 
> An operator at the beginning perhaps?
> 
> let fn1 = #someA.someFunc(a: Int) -> Int
> let fn2 = #someA.someFunc(a: Int) -> Double
> let fn3 = #someA.someFunc(a: Double) -> Int
> let fn4 = #someA.someFunc(a: Double) -> Double

Well, this works today:

let fn1: Int -> Int = someA.someFunc
let fn2: Int -> Double = someA.someFunc
let fn3: Double -> Int = someA.someFunc
let fn4: Double -> Double = someA.someFunc

In fact, this too works:

let fn1: (a: Int) -> Int = someA.someFunc
let fn2: (a: Int) -> Double = someA.someFunc
let fn3: (a: Double) -> Int = someA.someFunc
let fn4: (a: Double) -> Double = someA.someFunc

See the parameter name in the type? It could be used to disambiguate, but 
currently it is not taken into account: if you add a `someFunc` overload taking 
a different parameter name but the same types the above code becomes ambiguous.

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Wallacy via swift-evolution]

How to differentiate these functions?

class A{
func someFunc(a: Int) -> Int{
return 0;
}
func someFunc(a: Int) -> Double{
return 0;
}
func someFunc(a: Double) -> Int{
return 0;
}
func someFunc(a: Double) -> Double{
return 0;
}
   func someFunc(a: Int, b: Int) -> Int{
return 0;
}
}

Even with backticks would not be possible.

You may need to reference the method signature altogether.

var someA = A()

*let fn1 = someA.#someFunc(a: Int) -> Int*


*let fn2 = someA.#someFunc(a: Int) -> Double let fn3 = someA.#someFunc(a:
Double) -> Int let fn4 = someA.#someFunc(a: Double) -> Double*

An operator at the beginning perhaps?

let fn1 = #someA.someFunc(a: Int) -> Int
let fn2 = #someA.someFunc(a: Int) -> Double
let fn3 = #someA.someFunc(a: Double) -> Int
let fn4 = #someA.someFunc(a: Double) -> Double


You may not need the full signature all the time, only necessary to
differentiate.

extension A {
func someOtherFunc(a: Int, b: Int) -> Int{
return 0;
}
func someOtherFunc(){
}
func someOther(){
}
}

*let fn5 = someA.#someOtherFunc(a:, b:)*
*let fn6 = someA.#someOtherFunc()*
*let fn6 = someA.someOther*

Another possibility:

*let fn5 = #(someA.someOtherFunc(a:, b:))*
*let fn5 = @(someA.someOtherFunc(a:, b:))*

Thus the parser can try to just focus on what's inside the *#(*...*) or *
*@(*...*)*

Em dom, 27 de dez de 2015 às 22:27, John McCall via swift-evolution <
swift-evolution@swift.org> escreveu:

> > On Dec 27, 2015, at 4:15 PM, Chris Lattner  wrote:
> >
> > On Dec 27, 2015, at 4:09 PM, John McCall  wrote:
> >>> I’m a fan of good error recovery, but I don’t think it is a major
> concern here for two reasons:
> >>>
> >>> 1) The most common case in a method will lack a label, and
> "thing.foo(_: “ and “thing.foo(:” are both unambiguously a curried
> reference.
> >>> 2) A common case of accidentally completing a nullary call
> (thing.foo() vs thing.foo) will produce a type error.  We already produce
> good QoI for an unapplied function - adding the inverse would be simple.
> >>>
> >>> Further, it will be uncommon *in general* to form a curried reference,
> so error recovery doesn’t have to be perfect in all the edge cases.  As
> with other commenters, if it is at all possible to avoid the extra
> backticks, I’d really prefer that.
> >>
> >> The concern, I think, is that a messed-up normal call might look like a
> curried reference.
> >>
> >> My inclination would be to go the other way: if we get a syntax for
> this that we like, I think we should use it for *all* curried member
> references, and reject things like foo.bar in favor of foo.`bar`.  The
> ability to write foo.bar for a method has always struck me as more clever
> than wise, to be honest.
> >
> > If you were to go that far, I’d suggest looking at this as a different
> version of the “." operator.  If you resyntax curried to something else
> like (just a strawman, intentionally ugly syntax):
> >
> >   foo.#bar
> >
> > Then you’d get a nice property that the plain old dot operator always
> has to be fully applied.  This certainly would be a win for error
> recovery.  Also, if you did this, you wouldn’t need the backticks from
> doug’s proposal either for things like:
> >
> >   foo.#bar(param1:param2:)
> >
> > either.
>
> Right.  I really like this effect.
>
> I’m not that bothered by requiring the backticks, especially because it
> generalizes well to non-member function references, which I’m not sure any
> sort of different-member-access syntax does.
>
> John.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Chris Lattner via swift-evolution]

> On Dec 27, 2015, at 4:27 PM, John McCall  wrote:
> 
>> On Dec 27, 2015, at 4:15 PM, Chris Lattner  wrote:
>> 
>> On Dec 27, 2015, at 4:09 PM, John McCall  wrote:
 I’m a fan of good error recovery, but I don’t think it is a major concern 
 here for two reasons:
 
 1) The most common case in a method will lack a label, and "thing.foo(_: “ 
 and “thing.foo(:” are both unambiguously a curried reference.
 2) A common case of accidentally completing a nullary call (thing.foo() vs 
 thing.foo) will produce a type error.  We already produce good QoI for an 
 unapplied function - adding the inverse would be simple.
 
 Further, it will be uncommon *in general* to form a curried reference, so 
 error recovery doesn’t have to be perfect in all the edge cases.  As with 
 other commenters, if it is at all possible to avoid the extra backticks, 
 I’d really prefer that.
>>> 
>>> The concern, I think, is that a messed-up normal call might look like a 
>>> curried reference.
>>> 
>>> My inclination would be to go the other way: if we get a syntax for this 
>>> that we like, I think we should use it for *all* curried member references, 
>>> and reject things like foo.bar in favor of foo.`bar`.  The ability to write 
>>> foo.bar for a method has always struck me as more clever than wise, to be 
>>> honest.
>> 
>> If you were to go that far, I’d suggest looking at this as a different 
>> version of the “." operator.  If you resyntax curried to something else like 
>> (just a strawman, intentionally ugly syntax):
>> 
>>  foo.#bar
>> 
>> Then you’d get a nice property that the plain old dot operator always has to 
>> be fully applied.  This certainly would be a win for error recovery.  Also, 
>> if you did this, you wouldn’t need the backticks from doug’s proposal either 
>> for things like:
>> 
>>  foo.#bar(param1:param2:)
>> 
>> either.
> 
> Right.  I really like this effect.
> 
> I’m not that bothered by requiring the backticks, especially because it 
> generalizes well to non-member function references, which I’m not sure any 
> sort of different-member-access syntax does.

I’m bothered by it because it overloads backtick to mean two things: 
keywords-as-names, and annoying-sequences-of-tokens-as-names.  Either use would 
be acceptable to me, but the fact that we have to support one nested inside the 
other makes it pretty nasty.

-Chris

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution 
>  wrote:
> 
> Given that someView.insertSubview(_:at:) can be correctly parsed, I would 
> strongly lean towards the no-backtick alternative mentioned at the end. I 
> feel as though the backticks end up looking very cluttered (particularly when 
> you get into the double-nested backticks), and it seems cleaner to be able to 
> reference a method as it was declared rather than having to add extra syntax.
> 
> In reference to the issues noted with this approach:
> 
> IMO, there is already enough syntactic difference between getters/setters and 
> normal methods to justify requiring a different syntax to reference them. For 
> instance, the # syntax could be used so that, button.currentTitle.get would 
> reference Optional.get, and button.currentTitle#get would reference 
> the getter. Or, button.`currentTitle.get` could reference the getter (i.e. 
> backticks are only required in cases that are ambiguous).
> 
> I also think it is reasonable to require that in the case of a method with no 
> arguments such as set.removeAllElements, the programmer be expected to know 
> the difference between the expression with and without the trailing 
> parenthesis. After all, that distinction already exists in the language, and 
> would not disappear with this proposed addition. If a parallel syntax for 
> referencing methods with no arguments is strongly desired, perhaps something 
> such as set.removeAllElements(:), set#removeAllElements(), or similar could 
> be used, though I think that the present system for referencing these methods 
> is sufficient.
> 
> Are there other obvious reasons why this alternative wouldn’t work? I think 
> it is the cleanest of the alternatives and avoids littering the code with 
> backticks.

Not having the back-ticks means that you will need to use contextual type 
information to disambiguate the zero-parameter case from other cases. For 
example:

class Foo {
func doSomething() { }
func doSomething(value: Int) { }
}

let fn = Foo.doSomething // ambiguous
let fn2 = Foo.doSomething(_:) // okay
let fn3: (Foo) -> () -> Void = Foo.doSomething // okay
let fn3: (Foo) -> (Int) -> Void = Foo.doSomething // okay

My general complaint with the “drop the backticks” approach is that it doesn’t 
solve the whole problem. Sure, it solves 95% of the problem with a little less 
syntax, but now you need to invent yet another mechanism to handle the other 
cases (#set, contextual type disambiguation, etc)… which seems inconsistent to 
me.

- Doug


> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> Hi all,
>> 
>> Here’s a proposal draft to allow one to name any function in Swift. In 
>> effect, it’s continuing the discussion of retrieving getters and setters as 
>> functions started by Michael Henson here:
>> 
>>  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>  
>> 
>> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>  
>> 
>> 
>> Comments appreciated!
>> 
>> Generalized Naming for Any Function
>> 
>> Proposal: SE- 
>> 
>> 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, 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: Michael Henson started a thread about the 
>> getter/setter issue here 
>> ,
>>  continued here 
>> .
>>  See the Alternatives considered 
>> 
>>  section for 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Wallacy via swift-evolution]

*"if you add a `someFunc` overload taking a different parameter name but
the same types the above code becomes ambiguous."*

Yes, I know, I forgot this example. Ironically that was the intent, but I
do not choose good examples.

I was just exploring the idea of having to display the full signature at
some point.

Em dom, 27 de dez de 2015 às 23:11, Michel Fortin 
escreveu:

> Le 27 déc. 2015 à 19:54, Wallacy via swift-evolution <
> swift-evolution@swift.org> a écrit :
> > Even with backticks would not be possible.
> >
> > You may need to reference the method signature altogether.
> >
> > var someA = A()
> > let fn1 = someA.#someFunc(a: Int) -> Int
> > let fn2 = someA.#someFunc(a: Int) -> Double
> > let fn3 = someA.#someFunc(a: Double) -> Int
> > let fn4 = someA.#someFunc(a: Double) -> Double
> >
> > An operator at the beginning perhaps?
> >
> > let fn1 = #someA.someFunc(a: Int) -> Int
> > let fn2 = #someA.someFunc(a: Int) -> Double
> > let fn3 = #someA.someFunc(a: Double) -> Int
> > let fn4 = #someA.someFunc(a: Double) -> Double
>
> Well, this works today:
>
> let fn1: Int -> Int = someA.someFunc
> let fn2: Int -> Double = someA.someFunc
> let fn3: Double -> Int = someA.someFunc
> let fn4: Double -> Double = someA.someFunc
>
> In fact, this too works:
>
> let fn1: (a: Int) -> Int = someA.someFunc
> let fn2: (a: Int) -> Double = someA.someFunc
> let fn3: (a: Double) -> Int = someA.someFunc
> let fn4: (a: Double) -> Double = someA.someFunc
>
> See the parameter name in the type? It could be used to disambiguate, but
> currently it is not taken into account: if you add a `someFunc` overload
> taking a different parameter name but the same types the above code becomes
> ambiguous.
>
> --
> Michel Fortin
> https://michelf.ca
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[John McCall via swift-evolution]

> On Dec 27, 2015, at 4:02 PM, Chris Lattner via swift-evolution 
>  wrote:
> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution 
> > wrote:
>>> can be correctly parsed as a reference to insertSubview(_:at:). However, it 
>>> breaks down at the margins, e.g., with getter/setter references or 
>>> no-argument functions:
>>> 
>>> extension Optional {
>>>   func get() -> T { return self! }
>>> }
>>> 
>>> let fn1 = button.currentTitle.get   // getter or Optional.get?
>>> let fn2 = set.removeAllElements()   // call or reference?
>> From what I remember, the bigger concern with allowing foo(bar:bas:) without 
>> backticks is parser error recovery. The unambiguity with call syntax depends 
>> on having the `:)` token pair at the end. The edit distance between 
>> foo(bar:bas:) and a call foo(bar: bas) or work-in-progress call foo(bar: x, 
>> bas: ) is pretty slight, and would be tricky to give good diagnostics for. 
>> If we felt confident we could give good diagnostics, I'd support removing 
>> the backticks.
> 
> I’m a fan of good error recovery, but I don’t think it is a major concern 
> here for two reasons:
> 
> 1) The most common case in a method will lack a label, and "thing.foo(_: “ 
> and “thing.foo(:” are both unambiguously a curried reference.
> 2) A common case of accidentally completing a nullary call (thing.foo() vs 
> thing.foo) will produce a type error.  We already produce good QoI for an 
> unapplied function - adding the inverse would be simple.
> 
> Further, it will be uncommon *in general* to form a curried reference, so 
> error recovery doesn’t have to be perfect in all the edge cases.  As with 
> other commenters, if it is at all possible to avoid the extra backticks, I’d 
> really prefer that.

The concern, I think, is that a messed-up normal call might look like a curried 
reference.

My inclination would be to go the other way: if we get a syntax for this that 
we like, I think we should use it for *all* curried member references, and 
reject things like foo.bar in favor of foo.`bar`.  The ability to write foo.bar 
for a method has always struck me as more clever than wise, to be honest.

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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Frederick Kellison-Linn via swift-evolution]

Commentary inline below.

FKL

> On Dec 27, 2015, at 8:40 PM, Douglas Gregor  wrote:
> 
> 
>> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution 
>>  wrote:
>> 
>> Given that someView.insertSubview(_:at:) can be correctly parsed, I would 
>> strongly lean towards the no-backtick alternative mentioned at the end. I 
>> feel as though the backticks end up looking very cluttered (particularly 
>> when you get into the double-nested backticks), and it seems cleaner to be 
>> able to reference a method as it was declared rather than having to add 
>> extra syntax.
>> 
>> In reference to the issues noted with this approach:
>> 
>> IMO, there is already enough syntactic difference between getters/setters 
>> and normal methods to justify requiring a different syntax to reference 
>> them. For instance, the # syntax could be used so that, 
>> button.currentTitle.get would reference Optional.get, and 
>> button.currentTitle#get would reference the getter. Or, 
>> button.`currentTitle.get` could reference the getter (i.e. backticks are 
>> only required in cases that are ambiguous).
>> 
>> I also think it is reasonable to require that in the case of a method with 
>> no arguments such as set.removeAllElements, the programmer be expected to 
>> know the difference between the expression with and without the trailing 
>> parenthesis. After all, that distinction already exists in the language, and 
>> would not disappear with this proposed addition. If a parallel syntax for 
>> referencing methods with no arguments is strongly desired, perhaps something 
>> such as set.removeAllElements(:), set#removeAllElements(), or similar could 
>> be used, though I think that the present system for referencing these 
>> methods is sufficient.
>> 
>> Are there other obvious reasons why this alternative wouldn’t work? I think 
>> it is the cleanest of the alternatives and avoids littering the code with 
>> backticks.
> 
> Not having the back-ticks means that you will need to use contextual type 
> information to disambiguate the zero-parameter case from other cases. For 
> example:
> 
>   class Foo {
>   func doSomething() { }
>   func doSomething(value: Int) { }
>   }
> 
>   let fn = Foo.doSomething // ambiguous
>   let fn2 = Foo.doSomething(_:) // okay
>   let fn3: (Foo) -> () -> Void = Foo.doSomething // okay
>   let fn3: (Foo) -> (Int) -> Void = Foo.doSomething // okay

Why does Foo.doSomething have to be ambiguous? I would say that if this system 
is implemented (especially if without backticks), Foo.doSomething should only 
be able to refer to the no-argument overload of doSomething (i.e. "let fn3: 
(Foo) -> (Int) -> Void = Foo.doSomething" would be an error). This would break 
existing code that relies on the type disambiguation, but we would be able to 
offer a replacement for it.

> My general complaint with the “drop the backticks” approach is that it 
> doesn’t solve the whole problem. Sure, it solves 95% of the problem with a 
> little less syntax, but now you need to invent yet another mechanism to 
> handle the other cases (#set, contextual type disambiguation, etc)… which 
> seems inconsistent to me.

I feel as though backticks are the inconsistent approach in this case, 
especially because they already have one meaning in Swift that is used in the 
same context (as Chris notes). The 'natural' solution to me would be to refer 
to method references by writing them like a call without arguments, just like 
the name of a selector in Objective C.

Backticks also have the unfortunate properties of being relatively unknown 
characters to those who may not have a lot of programming experience, and at 
first glance are hard to differentiate from single quotes. In the context of 
using keywords as identifiers, I don't see those to be as big of issues, 
because except in very specific cases the easier solution is simply "come up 
with a different name for your identifier". To have to use backticks whenever a 
method reference is desired is, IMO, confusing and cluttered syntax.

I think that the best solution is to extend the current syntax as naturally as 
possible, and only introduce the backticks (or other syntax) as needed in cases 
such as obj.`property.get` (or obj.property#get). Obviously my notion of 
'natural' is going to differ from others', but I think that most would agree 
that being able to write "Foo.doSomething(_:bar:)" is a more intuitive 
extension of the syntax than "Foo.`doSomething(_:bar:)`.

> 
>   - Doug
> 
> 
>>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> Here’s a proposal draft to allow one to name any function in Swift. In 
>>> effect, it’s continuing the discussion of retrieving getters and setters as 
>>> functions started by Michael Henson here:
>>> 
>>> 
>>> 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Thorsten Seitz via swift-evolution]

> Am 28.12.2015 um 01:15 schrieb Chris Lattner via swift-evolution 
> :
> 
> (just a strawman, intentionally ugly syntax):
> 
>foo.#bar

Much prettier than backticks IMHO.

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