<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
I think #1 is reasonable.<br>
<br>
I don't think #3 is in practice that bad, though.<br>
<br>
Another variation on #3 is:<br>
<br>
6. Ban using function references as arguments/returns in overloaded
functions (for now).<br>
<br>
Note that Apple's Swift makes heavy use of type inference. It might
be useful to see how it handles this issue.<br>
<br>
An advantage to #1 is that we could add support for overloading at a
later time.<br>
<br>
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.<br>
<br>
- Mike<br>
<br>
<div class="moz-cite-prefix">On 1/27/15 9:42 PM, Tim Armstrong
wrote:<br>
</div>
<blockquote
cite="mid:CAC0jiV7OrKKe+_uZVJBW_rU3uSQuWfo7MSZkY6v=siNRHK21Dg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div>
<div>Hi All,<br>
</div>
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.<br>
<br>
.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.<br>
</div>
<div><br>
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:<br>
<br>
</div>
<div>reduce(0, [1, 10, 3, 4], max)<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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<br>
<br>
</div>
<div>There seems to be a number of ways to get around this
problem:<br>
</div>
<div>1. Don't support overloading at all, save complications at
the expense of longer function names<br>
</div>
<div>2. Don't plan on supporting function references at all<br>
</div>
<div>3. Ban using overloaded functions as first-class functions,
force users to work around it. <br>
</div>
<div>4. Attempt to do some basic type inference to disambiguate,
give up if we can't disambiguate from local information. (C++
approach, essentially)<br>
</div>
<div>5. Full program-wide type inference (Haskell approach)<br>
</div>
<div><br>
</div>
<div>#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.<br>
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.<br>
<br>
</div>
<div>Anyway, that was a bunch of detail - does anyone have any
thoughts or opinions? Have I missed anything?<br>
</div>
<div><br>
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</div>
<div><br>
</div>
<div>- Tim<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Swift-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a>
<a class="moz-txt-link-freetext" href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Wilde
Mathematics and Computer Science Computation Institute
Argonne National Laboratory The University of Chicago
</pre>
</body>
</html>