[Swift-devel] Reconsidering function overloading

[Tim Armstrong]

I think lambdas are a nice orthogonal way to solve it here, but yeah, I
don't think they're in the plans in the immediate future.

- Tim

On Wed, Jan 28, 2015 at 2:39 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150128/89ac514d/attachment.html>