[Swift-devel] Reconsidering function overloading

[Mihael Hategan]

Which ultimately isn't much different from having to do:

(float x) minFloat(float[] a) {
  x = min(a);
}

reduce(a, minFloat);

So maybe that isn't much progress.

Mihael

On Wed, 2015-01-28 at 12:23 -0800, Mihael Hategan wrote:
> 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
> 
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel