[Swift-devel] Reconsidering function overloading

[Mihael Hategan]

Here's another idea. If we do support lambda expressions, then:

- a direct reference to an overloaded function when no parameter type is
available should result in an ambiguity error
- a user can resolve the issue by writing an explicit lambda expression
which calls the overloaded function, but this time with normal parameter
type information available

E.g:

min = reduce(a, min); // error
min = reduce(a, lambda(float x) { return min(x); });

This requires no specialized casting mechanism. Of course, if lambda
expressions weren't in the plans, this might be more work.

Mihael

On Tue, 2015-01-27 at 21:42 -0600, Tim Armstrong wrote:
> 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
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel