[Swift-devel] Reconsidering function overloading
Michael Wilde
wilde at anl.gov
Wed Jan 28 07:17:48 CST 2015
One more possibility occurs: could we allow overloaded functions to
pass/return function reference args if we required that when a function
reference arg is overloaded, it must be passed with a disambiguating
type signature?
I.e. if we have:
max( float[ ] )
max( int[ ] )
sum( int[ ] )
reduce(T, T[ ], (T) f ( int[ ] ) )
Then we have to say:
reduce(0, [1, 10, 3, 4], max( int[ ] ) )
but we could also say:
reduce(0, [1, 10, 3, 4], sum )
And if we wanted uniformity over convenience we could insist that
function references must always be passed with type signatures even when
unambiguous.
Does that approach work consistently and reasonably?
- Mike
On 1/28/15 7:07 AM, Michael Wilde wrote:
>
> 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
>
>
> _______________________________________________
> 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/6f5f683c/attachment.html>
More information about the Swift-devel
mailing list