First, if you aren't familiar with the issue, read http://www.digitalmars.com/d/2.0/function.html#overload-sets .  As has been discussed before in the NG, we have the concept of overload sets because we don't want 2 modules which accidentally use the same function names to end up confusing each other's overload rules.  (Similarly, we have the problem with classes...if you define a function that shares a name with some deeply-buried class in a library, are you overloading the function, or accidentally defining a coincidence?)

The workaround, if you want to merge two moduless' sets, is to use "alias" declarations in one of them.  However, I think that I have a better idea.

Let's say that a fully-qualified name (a.b.c.myFunc) functions as a symbol which is distinct from any non-qualified name (myFunc).  Now, we can use that symbol in any *other* module to explicitly say "this new thing that I'm defining is an overload of that other known thing."

Likewise, when you *use* the symbol, you are accessing the entire overload set (including the add-ons).  (NOTE: Since the original module doesn't know about any of its add-ons, you are only overloading using the things that you have defined using your imports.  See example below.)


EXAMPLE CODE (PROPOSED SYNTAX)
  "a.d"
    int myFunc(int);

  "b.d"
    import a;
    int a.myFunc(char);

  "c.d"
    import a;
    a.myFunc('x'); // calls a.myFunc(int)

  "d.d"
    import a;
    import b;
    a.myFunc('x'); // calls b.myFunc(char)
END CODE


Advantages:
* Import any new module and add overloads to an *old* overload set
* Access the entire overload set (including add-ons) with the name of the root.  Think about the canonical example of a "Shape" class...
* Easily handles the case where you have 2 add-on modules to the same base module (hard to do with 'alias').


CLASSES

This has immediate applicability to classes.  An easy syntax for overloading would be to reference the (original) base class or interface where the overloaded-function was defined.  If you don't provide that name, then D would assume that this is a new, unrelated function. (Question: How would we handle the gradual transition to this model?)


EXAMPLE CODE (PROPOSED)

library.d:
  class A
  {
    int foo();
  }
  class B : A
  {
    int A.foo(); // overloads A.foo
  }

myProgram.d:
  import library;
  class C : B
  {
    int foo(); // UNRELATED to A.foo!
  }


  A myVar = new C;
  myVar.foo(); // calls B.foo()
  C myVar_C = cast(C)myVar;
  myVar.foo(); // calls C.foo()


THOUGHTS?

Russell Lewis Wrote:

> 
> EXAMPLE CODE (PROPOSED)
> 
> library.d:
>    class A
>    {
>      int foo();
>    }
>    class B : A
>    {
>      int A.foo(); // overloads A.foo
>    }
> 
> myProgram.d:
>    import library;
>    class C : B
>    {
>      int foo(); // UNRELATED to A.foo!
>    }
> 
> 
>    A myVar = new C;
>    myVar.foo(); // calls B.foo()
>    C myVar_C = cast(C)myVar;
>    myVar.foo(); // calls C.foo()
> 
> 
> THOUGHTS?

Just wanted to bump this because it seemed like it was worth discussing  but got lost in the high traffic of the weekend.

Paul

Russell Lewis wrote:
> Likewise, when you *use* the symbol, you are accessing the entire overload set (including the add-ons).  (NOTE: Since the original module doesn't know about any of its add-ons, you are only overloading using the things that you have defined using your imports.  See example below.)

Let me restate this in a better way (I really struggled to explain it in my original post):

The idea is that when you use an unqualified name, this name is mapped by the compiler to some fully-qualified name (basically like current overload sets work).  We then calculate the set of possible overloads as if the user had used the fully-qualified name.

Of course, just like the current overload sets design, if there is any ambiguity, then the compiler produces an error.