<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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?<br>
    <br>
    I.e. if we have:<br>
    <br>
    � max( float[ ] )<br>
    � max( int[ ] )<br>
    � sum( int[ ] )<br>
    � reduce(T, T[ ], (T) f ( int[ ] ) )<br>
    <br>
    Then we have to say:<br>
    <br>
    �� reduce(0, [1, 10, 3, 4], max( int[ ] ) )<br>
    <br>
    but we could also say:<br>
    <br>
    �� reduce(0, [1, 10, 3, 4], sum )<br>
    <br>
    And if we wanted uniformity over convenience we could insist that
    function references must always be passed with type signatures even
    when unambiguous.<br>
    <br>
    Does that approach work consistently and reasonably?<br>
    <br>
    - Mike<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 1/28/15 7:07 AM, Michael Wilde
      wrote:<br>
    </div>
    <blockquote cite="mid:54C8DF25.9030301@anl.gov" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <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">
        <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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a>
<a moz-do-not-send="true" 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>
      <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>