Re: Re: overloaded method with context bounds seen as ambiguous

Thanks Paul. I thought it must have been scope related but I didn't test
changes to access modifiers. I'm curious if anyone else has been bitten
by this. I try to avoid overloading and I think many people do as a
general guideline (I've altered mine to work around this), so I'm
reluctant to open a bug requiring special casing that affects a feature
of the language I actively try to avoid.

On a final note, if you were to implement a special case, it seems the
rule would be to fail on any overloaded curried functions whose scopes
are identical, not simply public. That is:

object foo {
private[foo] def ovr(s: String)(i: Int) = s + i
private[foo] def ovr(s: String)(s2: String) = s + s2
}

suffers the same problem as the all public version, does it not? These
methods can never be disambiguated because they share the same scope.

Thanks for setting me straight.

-chris

On 08/21/2011 10:57 PM, Paul Phillips wrote:
> On 8/21/11 11:26 AM, Chris Lewis wrote:
>> object foo {
>> def ovr(s: String)(i: Int) = s + i
>> def ovr(s: String)(s2: String) = s + s2
>> }
>>
>> Even though they appear distinguishable when defined, as soon as
>> either is called, the compiler fails at the call site. Therefore,
>> even if definable, neither version can ever be referenced or the
>> compiler will fail.
>>
>> Can someone please explain why this is expected, or concur that it is
>> a bug.
> In the general case, ambiguity is a function of the call site, not the
> definition.
>
> object foo {
> private[foo] def ovr(s: String)(i: Int) = s + i
> def ovr(s: String)(s2: String) = s + s2
> }
>
> This is ambiguous inside foo, but not outside it. It is a potential
> enhancement to special-case and statically fail the curried overload
> where all participants are public, but it isn't a bug that this isn't
> done.
>