[Review] Naming Functions with Argument Labels

Hi Joe,

Do you have a plan for selecting between class and instance methods with the same name?

Excellent question! Swift’s overload resolution has some built-in preferences for picking static methods when referencing based on a metatype and for picking instance methods when referencing based on an instance, e.g.,

class X {
  static func f0() -> Int { return 0 }
  func f0() -> String { return "" }
}

let fn1 = X.f0 // () -> Int
let x = X()
let fn2 = x.f0 // () -> String

So one might have to conjure up an instance to force the instance method, or use type context to force the issue:

let fn3: (X) -> () -> String = X.f0

but it can be done without extra syntax.

From what I understand, the above will only work if the method names are the same but the type signature is different, otherwise you'd need to conjure up an instance. Is that correct?

Would it be strange to use X.f0 to refer to the instance method, and X.self.x0 to refer to the static method?

—Nathan

···

On Jan 14, 2016, at 5:50 PM, Douglas Gregor <dgregor@apple.com> wrote:

On Jan 13, 2016, at 4:36 PM, Nathan de Vries via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 14, 2016, at 4:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe
Review Manager

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

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

Doug / Joe,

Sorry about asking this after the review period: it's not clear to me how
the assigned functions can be called.

In case I have:

    let fn1 = someView.insertSubview(_:aboveSubview:)
    let fn2 = someView.insertSubview(_:belowSubview:)

will the types of both fn1 and fn2 be the same (i.e., (UIView, UIView) ->
())? Will I be able to call them without having to use the
aboveSubview/belowSubview labels, like:

    fn1(view1, view2)
    fn2(view3, view4)

Thanks,
roop.

···

On Wed, Jan 13, 2016 at 10:50 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

On Jan 13, 2016, at 9:16 AM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs
through January 10th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

Sorry, Mail mangled the link here, and the review runs through January *18th.
*Here's the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md

-Joe

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

Doug,

Given a struct like this:

struct MyStruct {
    func sampleMethod(arg1:String, arg2: Int) -> String {
        return "Hello"
    }
    func sampleMethod(arg1:String, arg2: Int) -> Int {
        return 42
    }
}

Would this force the following?

let myStruct = MyStruct()
let myStructFn1: (String, Int) -> String = myStruct.sampleMethod(_:arg2:)
let myStructFn2: (String, Int) -> Int = myStruct.sampleMethod(_:arg2:)

If you have multiple methods with the same name, you’ll need type context to disambiguate. You can use “as” if you don’t want to introduce a new variable, e.g.,

  myStruct.sampleMethod(_:arg2:) as (String, Int) -> String

You could grab the curried method from the class if you don’t want to create an instance, e.g.,

  MyStruct.sampleMethod(_:arg2:) as (MyStruct) -> (String, Int) -> String

  - Doug

···

On Jan 14, 2016, at 11:13 AM, David J. Ehrlich <david@ehrlichfamily.us> wrote:

Thanks,
—David

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

On Jan 13, 2016, at 4:36 PM, Nathan de Vries via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi Joe,

Do you have a plan for selecting between class and instance methods with the same name?

Excellent question! Swift’s overload resolution has some built-in preferences for picking static methods when referencing based on a metatype and for picking instance methods when referencing based on an instance, e.g.,

class X {
  static func f0() -> Int { return 0 }
  func f0() -> String { return "" }
}

let fn1 = X.f0 // () -> Int
let x = X()
let fn2 = x.f0 // () -> String

So one might have to conjure up an instance to force the instance method, or use type context to force the issue:

let fn3: (X) -> () -> String = X.f0

but it can be done without extra syntax.

  - Doug

—Nathan

On Jan 14, 2016, at 4:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe
Review Manager

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

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

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

Strong +1 on the proposal and on the syntax. I find that it passes the
"principle of least surprise", personally it's what I would expect the
language to accept.
Looking forward to this!

···

On Wed, Jan 13, 2016 at 9:04 PM Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote:

Without posting a full review, I’ll just drop a note in favor of the
proposed syntax (underscores for anonymous args, colons, no commas,
typically formatted with no spaces). This is exactly what we settled on
more or less by default when adding robust autolinking to Jazzy:

Support autolinking more than top-level declarations · Issue #328 · realm/jazzy · GitHub

This syntax is already widely used enough that I considered it an already
established informal Swift standard at the time, and I’m not aware of any
complaints about it from Jazzy users.

Cheers, P

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

--
Javier Soto

Doug / Joe,

Sorry about asking this after the review period: it's not clear to me how the assigned functions can be called.

In case I have:

    let fn1 = someView.insertSubview(_:aboveSubview:)
    let fn2 = someView.insertSubview(_:belowSubview:)

will the types of both fn1 and fn2 be the same (i.e., (UIView, UIView) -> ())? Will I be able to call them without having to use the aboveSubview/belowSubview labels, like:

    fn1(view1, view2)
    fn2(view3, view4)

Right now, you'll still need to use labels in the call. However, this is an area where we'd like to revisit things a bit: having labels in function types seems to cause more trouble than it provides benefits, and I'd like to see up address that directly.

  - Doug

···

Sent from my iPhone

On Jan 18, 2016, at 11:53 PM, Roopesh Chander via swift-evolution <swift-evolution@swift.org> wrote:

Thanks,
roop.

On Wed, Jan 13, 2016 at 10:50 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md

Sorry, Mail mangled the link here, and the review runs through January 18th. Here's the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md

-Joe

_______________________________________________
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