<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 10/5/2018 7:22 PM, Dan Smith wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:7F5E0D67-0A18-47E0-9767-D474BA4E52D7@oracle.com">
      <div class="">- It's not totally clear what we do with 'this'.
        Kind of seems like it should be treated as the first parameter
        to be passed, but there are also examples in the JEP that ignore
        it. And is it allowed to be referenced by the receiver
        expression?</div>
      <div class=""><br class="">
      </div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre">     </span>void
        reverse() = Collections::reverse; // invoke
        Collections.reverse(this)?</div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre">     </span>int
        length(String s) = String::length; // invoke s.length()?</div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre">     </span>void
        altMethod() = ThisClass::method; // invoke this.method()?</div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre">     </span>void
        altMethod2() = this::method; // legal?</div>
    </blockquote>
    <br>
    <tt>Drilling in on `this`: <br>
      <br>
      One of the strongest motivating examples was:<br>
      <br>
          static final Comparator c = ...<br>
      <br>
          int compareTo(T other) = c::compare;<br>
      <br>
      And in this case, we want this to wire to c.compare(this, other). 
      <br>
      <br>
      However, another strong motivating case is: <br>
      <br>
          final List myList = ...<br>
      <br>
          int size() = myList::size;<br>
      <br>
      in which case we want this to wire to myList.size() and ignore
      `this` entirely.  <br>
      <br>
      And, both use cases are equally desirable.  <br>
      <br>
      We have some precedent for resolution that involves "try both",
      which is the Class::method syntax, where we'll match either an
      instance method or a static method passing the receiver as the
      first parameter.  However, this is a little different; in that
      case, we were still using all the parameters, just adapting them
      to paper over the somewhat accidental static/instance divide.  In
      this case, we want to drop the receiver when the wired-to method
      doesn't want it, which is a little messier.  But, also not totally
      novel; when adapting a value-returning method reference to a
      void-returning SAM, we are willing to drop the return value.  <br>
      <br>
      There are (at least) two ways we could attack this.  The first
      involves refining the "infer a target type from the method
      descriptor, and then use that for overload selection" intuition.  
      Just as with Class::method, where we use the target type to do
      overload selection for both static and instance methods, and fail
      if we find neither or both, we can do the same thing; construct
      both the with-receiver and without-receiver SAM, and fail if there
      is not exactly one answer.  <br>
      <br>
      The other approach, which also leans on an existing precedent, is
      to start with the method reference; if it exact, use that to
      condition the adaptation to the implied SAM.  Which is slightly
      weaker that the first approach, as the exactness test can be
      fooled by inapplicable overloads (say, with completely wrong
      arity, or incompatible types.)  <br>
      <br>
      We already discourage overloads like:<br>
      <br>
          class C {<br>
              static R x(C c, ARGS)<br>
              R x(ARGS)<br>
          }<br>
      <br>
      because that will make method references C::x ambiguous.  With the
      approaches above, we'd also have ambiguities in cases like:<br>
          <br>
          class X {<br>
              void m() = Bar::m;<br>
          }<br>
      <br>
          class Bar {<br>
              static void m(X x, ARGS) { }<br>
              static void m(ARGS) { }<br>
          }<br>
      <br>
    </tt>That seems somewhat unlikely, but it becomes slightly more
    imagineable when you have something like:<br>
    <br>
    <tt>    class X implements I {<br>
              void m() = Bar::m;<br>
          }<br>
      <br>
          class Bar {<br>
              static void m(I i, ARGS) { }<br>
              static void m(ARGS) { }<br>
          }<br>
      <br>
      But still, it doesn't seem like we'd be overrun with these.<br>
      <br>
      <br>
      Summary:<br>
      <br>
       - Both the capture-this and drop-this cases have important
      motivating use cases<br>
       - Arbitrarily dropping one or the other would compromise the
      feature<br>
       - There are some possibly reasonable ways of doing overload
      resolution and adaptation here, at some complexity.<br>
      <br>
      <br>
      <br>
    </tt>
  </body>
</html>