<div dir="ltr"><div><div>Hi All,<br></div>  I was just starting to look at implementing the function overloading support required by the current design of the standard library.  I've just realised some of the complications and wanted to reassess the current design.<br><br>.As soon as I looked at the changes needed, it was obvious that it interacts with function references in ways that are probably undesirable.  The issue is that a function name maps to more than one function, and the compiler needs to be able to disambiguate wherever it is used: in a variable context as well as a function call context.<br></div><div><br>For example, suppose we wanted to provide a reduce function with type reduce(T, T[], (T) f (T, T)).  It seems reasonable that we'd want to be able to write:<br><br></div><div>reduce(0, [1, 10, 3, 4], max)<br><br></div><div>But if max is overloaded, then we have to be able to infer from the type of the first and second arguments which max was meant.<br><br></div><div>As an aside, there's a further level of difficulty in resolving things correctly if you consider that overloaded functions can take overloaded functions as arguments<br><br></div><div>There seems to be a number of ways to get around this problem:<br></div><div>1. Don't support overloading at all, save complications at the expense of longer function names<br></div><div>2. Don't plan on supporting function references at all<br></div><div>3. Ban using overloaded functions as first-class functions, force users to work around it. <br></div><div>4. Attempt to do some basic type inference to disambiguate, give up if we can't disambiguate from local information. (C++ approach, essentially)<br></div><div>5. Full program-wide type inference (Haskell approach)<br></div><div><br></div><div>#2 doesn't fit with overall plans for the project, I don't think. #3 seems pretty unsatisfying and I think we're best to avoid bad programmer experiences when we have a cleanish slate to work from.     #5 doesn't seem feasible without major changes to language and compiler.<br>This leaves #1 and #4.  I think I could make #4 work in Swift/T, but it would be days of work and getting all the corner cases may be a challenge - realistically I might just not get it done.  I have no idea how feasible #4 is in Swift/K. #1 seems like the best effort to reward ratio to me.<br><br></div><div>Anyway, that was a bunch of detail - does anyone have any thoughts or opinions?  Have I missed anything?<br></div><div><br>I'm already assuming that we just shouldn't support 
overloading functions with any other kind of polymorphic 
arguments - it's not really necessary and too complicated to implement</div><div><br></div><div>- Tim<br></div></div>