Re: Overloading methods with multiple parameter lists makes for "syntactic mismatch"

There are a few degrees of freedom, or if you prefer, enough rope to hang
by.

scala> trait Y { def a(x: Int) = x }
defined trait Y

scala> object X extends Y { def a(x: Int)(y: Int) = x + y }
defined object X

scala> X.a(2)(3)
res0: Int = 5

scala> (X.a _ : Int => Int)(42)
res1: Int = 42

scala> (X: Y).a(42)
res2: Int = 42

Members that are hard to invoke.

scala> object B { def f(i: Int) = 42 + i ; def f(i: => Int) = 42 * i }
defined object B

scala> B.f(1)
res4: Int = 43

I'd hoped g to invoke the second f because of the shape of a by-name param.

scala> object B {
     | def f(i: Int) = 42 + i
     | def f(i: => Int) = 42 * i
     | def g(i: => Int) = f(i) + 100
     | }
defined object B

scala> B.f(1)
res5: Int = 43

scala> B.g(1)
res6: Int = 143

Against the notion that adding an arg list is obvious to humans. This is a
puzzler, or was.

scala> List(1,2,3).toSet()
warning: there was one deprecation warning; re-run with -deprecation for
details
res7: Boolean = false



On Thu, Jul 9, 2015 at 4:34 PM, Nils Kilden-Pedersen <[email protected]>
wrote:

> On Thu, Jul 9, 2015 at 6:18 PM, mar <[email protected]> wrote:
>
>> The following compiles without warnings:
>>
>> object X {
>>     def a(x: Int) = x
>>     def a(x: Int)(y: Int) = x + y
>> }
>>
>> Actually trying to use either method gives me a compilation error even
>> though, in my mind, there is no ambiguity: X.a(1) without curryscore
>> would be the first one whereas X.a(1)(2) is the second.
>>
>> Defining *a* such that implicit val zero = 0; def a(x: Int)(implicit y:
>> Int) = x + y is a less-than-optimal workaround but what strikes me is
>> that in this case Scala is able to figure out the signature when explicitly
>> providing the second parameter item. Why is it eagerly failing in the first
>> case when it awaits the possible explicit value in the second?
>>
>> I find this rather confusing and "mentally overloading"
>>
> https://issues.scala-lang.org/browse/SI-2628
>
>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "scala-language" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.