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

[Wallacy]

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 at swift.org> escreveu:

> > On Dec 27, 2015, at 4:15 PM, Chris Lattner <clattner at apple.com> wrote:
> >
> > On Dec 27, 2015, at 4:09 PM, John McCall <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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151228/3e31071f/attachment.html>