[Swift-devel] Reconsidering function overloading

[Tim Armstrong]

Hi All,
  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.

.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.

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:

reduce(0, [1, 10, 3, 4], max)

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.

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

There seems to be a number of ways to get around this problem:
1. Don't support overloading at all, save complications at the expense of
longer function names
2. Don't plan on supporting function references at all
3. Ban using overloaded functions as first-class functions, force users to
work around it.
4. Attempt to do some basic type inference to disambiguate, give up if we
can't disambiguate from local information. (C++ approach, essentially)
5. Full program-wide type inference (Haskell approach)

#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.
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.

Anyway, that was a bunch of detail - does anyone have any thoughts or
opinions?  Have I missed anything?

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

- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150127/2f33876e/attachment.html>