I just had an idea regarding overloading: A method can have two names, one has to be unique and is used for reflection, the other one is what you normally use in source. If you don't provide an internal name explicitly the normal name is used as internal name, too.

In the following example there are two methods send and sendWithIPAsString, but you can call both just by using send.

class Foo {
   // normal name: send, internal name: sendWithIPAsString
   Void send ~sendWithIPAsString(Str ip)
   {
      send(IpAddr(ip))
   }

   // normal name: send, internal name: send
   Void send (IpAddr ip)
   {
      ...
   }
}

usage

foo := Foo()
foo.send("192.168.0.1")  // resolves to sendWithIPAsString

This might solve the operator overloading problem as well.

class DateTime
{
   Duration minus ~minusDateTime(DateTime) { ... }
   DateTime minus ~minusDuration(Duration) { ... }
}

It's not a bad idea, it just seems like it would put more burden on developer instead of the compiler. For example what happens here?

Void get ~getFloatSendNothing (Float f) {...}
Int get ~getIntSendInt (Int i) {...}
...
f := Foo.get(i) 

Can f even be Void?

I actually don't want to encourage use of overloaded methods, so I don't think we should build a mechanism that effectively allows that. My thinking is overloads should be a special case for:

1. operators
2. handling FFI overloads