[Swift-devel] Reconsidering function overloading

[Michael Wilde]

I think #1 is reasonable.

I don't think #3 is in practice that bad, though.

Another variation on #3 is:

6. Ban using function references as arguments/returns in overloaded 
functions (for now).

Note that Apple's Swift makes heavy use of type inference. It might be 
useful to see how it handles this issue.

An advantage to #1 is that we could add support for overloading at a 
later time.

A point in favor of #3 or #6 is that we've lived without either feature 
till now; a few restrictions on the pair of new features will not be 
very limiting. I don't think it will lead to many "bad programmer 
experiences", although I agree that its a wart from a language design 
perspective.

- Mike

On 1/27/15 9:42 PM, 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

-- 
Michael Wilde
Mathematics and Computer Science          Computation Institute
Argonne National Laboratory               The University of Chicago

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