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

[John McCall]

> On Dec 27, 2015, at 4:54 PM, Wallacy <wallacyf at gmail.com> wrote:
> How to differentiate these functions?

Doug talked about this some in his proposal.

John.

> 
> 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 at swift.org <mailto:swift-evolution at swift.org>> escreveu:
> > On Dec 27, 2015, at 4:15 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> >
> > On Dec 27, 2015, at 4:09 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151227/9a3c80ae/attachment.html>