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:
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
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:
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:
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
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:
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.
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: