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

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”

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

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?

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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`

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

> 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]?) {

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

> 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

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

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.

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

"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),

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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:

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

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; }

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

> 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

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

> 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

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

*"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

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

> 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

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

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,

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

> 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