Conflict in signatures with default values--why?

[Ken McDonald]

In the following two method signatures:

def nodes[N <: Node](dir: Direction, from: Int, prefix: Boolean = false, suffix: Boolean = false) =  {...}

def nodes[N <: Node](dir: Direction, prefix: Boolean = false, suffix: Boolean = false) = {...}

I'm getting compiler messages of the form "multiple overloaded alternatives of method nodes define default arguments."  This surprises me. The requirement for a "from" argument in the first case clearly disambiguates the two, so there can be no problem with choosing which alternative to use, regardless of what optional arguments are provided. I haven't seen any explanation for this in the blurbs about default values I've Googled.

I have looked at the formal spec (2.8--sorry, it's what I have on hand), and will have to read the second part on this topic several times more to understand it, but intuitively, one would think the above would make perfect sense to the compiler. Could someone comment, please?

Thanks,

Ken

[Tony Sloane]

I believe that 6.26.3, para starting "Otherwise, let S1, S2, ...", (2.9 spec, sorry), is saying that it is an error if all of the applicable alternatives involve a default argument.  This would be the case if those two definitions of nodes are the only ones you have.

Also, I believe the default argument paper said that only one alternative for a method can have default arguments, which is what the error message seems to be saying, but I can't find that in the spec right now. 

regards,

Tony

[Ken McDonald]

Huh, that's interesting, I wonder why that would be the case? Perhaps they are thinking ahead to future possibilities might require these conditions to assure disambiguation?

Too, it's quite inconvenient. I've changed my code around so that relevant functions use curried argument lists, and  defaults in the second arg list are calculated based on values in the first arg list--but it makes the code rather more obtuse, and I'm still running into corner casesl

Thanks Tony,

Ken

[Lukas Rytz]

On Fri, Oct 21, 2011 at 02:07, Ken McDonald <ykke...@gmail.com> wrote:

Huh, that's interesting, I wonder why that would be the case?

The reason is that we wanted a deterministic naming-scheme for the generated methods

which return default arguments. Inf you write

  def f(a: Int = 1)

the compiler generates

  def f$default$1 = 1

If you have two overloads with defaults on the same parameter position, we would

need a different naming scheme. But we want to keep the generated byte-code

stable over multiple compiler runs.