Good point. I hadn't thought about refinement types. I don't have a good answer short of devising an internal naming scheme for them, which might be more trouble than its worth.
I don't think the limitation is too onerous. As you say, defaults replace a common use for overloading. If put to a vote I wouldn't vote to hold up 2.8 over it. It's just that limitations and irregularities driven by implementation challenges tend to have an "arbitrary" feel to users who aren't involved in the implementation and I can foresee a lot of "why doesn't this work" messages in the mailing list around this issue in the future.
On Tue, Jun 2, 2009 at 6:17 AM, Lukas Rytz
<lukas.rytz@...> wrote:
On Tue, Jun 2, 2009 at 14:43, James Iry
<jamesiry@...> wrote:
Would it be feasible to mangle the getter's name using the parameter types of the overloaded methods?
def foo(x : T1 = xdef, y : T2 = ydef)
def foo(z : T3 = zdef, zz : T4 = zzdef)
def foo$T1$T2$defaul1 = xdef
def foo$T1$T2$defaul2 = ydef
def foo$T3$T4$default1 = zdef
def foo$T3$T4$default2 = zzdef
That would probably work, except that for some types it's not obvious
how to convert them into a name:
def foo(x: { def bar(): Int } = new { def bar() = 1 })
def foo(x: String = "uh")
What do people think, is it too much limitation if we restrict defaults
to one overloaded alternative? After all, defaults often allow you to get
rid of overloads.
Lukas
