> On Dec 27, 2015, at 4:54 PM, Wallacy <walla...@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@swift.org <mailto:swift-evolution@swift.org>> escreveu:
> > On Dec 27, 2015, at 4:15 PM, Chris Lattner <clatt...@apple.com
> > <mailto:clatt...@apple.com>> wrote:
> >
> > On Dec 27, 2015, at 4:09 PM, John McCall <rjmcc...@apple.com
> > <mailto:rjmcc...@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
