<div dir="ltr"><div>I think that sounds good to me. <br><br>I think with overloading, I might attempt to implement overloading in the generic way (such that it would support user-defined functions), but only enable it for library functions by default. This would let us experiment with it to see how it works, but reduces the possibility of bugs for the time being.<br><br></div><div>I think the keyword arguments needs some discussion. I was thinking that we'd have optional positional arguments only (like C++). I think in any case I'd like to put keyword arguments into the "future" category. I'm open to discussion but I think we can put that off too.<br></div><div><br></div>- Tim<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 2, 2015 at 1:01 AM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
This is to summarize what maybe we might agree on so that we can wrap<br>
things up a bit.<br>
<br>
For the immediate purpose of having a standard library:<br>
- allow overloading for library functions; we already allow it to some<br>
extent, so I don't see much reason why we should cherry-pick<br>
- any user function with the same name as an already defined function<br>
(user or library) is a compile-time error; this is no different from<br>
what is currently happening<br>
<br>
For the future maybe, with the will of the gods of software engineering:<br>
- allow overloading of user-defined functions<br>
- any overloads that can potentially be ambiguous should generate a<br>
compile-time error (aka. when {positionals1} = {positionals2} and<br>
{keywords1} ∩ {keywords2} != 0).<br>
- support function pointers/references<br>
- unqualified references to overloaded functions are compile-time errors<br>
- support lambda expressions<br>
- possible support for overloaded function reference disambiguation<br>
(e.g. casting, inference; exact method TBD).<br>
<br>
Do we have agreement on the first part? The second isn't relevant for<br>
the task at hand, but I thought I'd mention it.<br>
<br>
Mihael<br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</blockquote></div><br></div>