<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <blockquote type="cite"
      cite="mid:7F5E0D67-0A18-47E0-9767-D474BA4E52D7@oracle.com">
      <div class="">The challenge seems to be finding the right
        intuition.</div>
    </blockquote>
    <br>
    Yep.  The intent is to suggest that the behavior on the RHS is a
    "constant" of some sort with respect to some context, so that
    "assigning" it is definitional rather than mutative.  But this is
    still fuzzy, so we need to narrow this down.  The narrowest
    interpretation of constant (#1) would eliminate some of the most
    useful motivating cases for the feature, such as:<br>
    <br>
        class C implements Comparable<C> {<br>
            private lazy static final Comparator<C> comp =
    Comparator.of(...);<br>
    <br>
            public int compareTo(C other) = comp::compare;<br>
        }<br>
    <br>
    or<br>
    <br>
        class UnmodifiableFooWrapper<T> implements Foo<T> {<br>
            private final Foo<T> underlying;<br>
    <br>
            public void fooMethod1(args) = underlying::fooMethod1;<br>
            public int fooMethod2(args) = underlying::fooMethod2;<br>
            public long fooMethod3(args) = underlying::fooMethod3;<br>
    <br>
            public String fooMethod4(args) { <br>
                // do something extra here<br>
                return underlying.fooMethod4(args);<br>
            }<br>
        }<br>
    <br>
    If we were to eliminate these cases, much of the benefit goes away. 
    <br>
    <br>
    Your #2 would admit the first example (because the comparator field
    is final), but eliminate the second; #3, #4, and #5 would also admit
    the second.  <br>
    <br>
    Of all of them, #6 seems the worst, because it undermines the
    "definitional" intuition I was going for.  <br>
    <br>
    <blockquote type="cite"
      cite="mid:7F5E0D67-0A18-47E0-9767-D474BA4E52D7@oracle.com">
      <div class="">1) One interpretation is that the method reference
        must be a constant—something that can be translated into a JVM
        linkage instruction without executing any code. (Meanwhile, on
        the JVM side we've explored some features for declaring concrete
        methods without a Code attribute.)</div>
      <div class=""><br class="">
      </div>
      <div class="">2) Another interpretation is Brian's here: the
        evaluation of a method ref's receiver parameter occurs at class
        initialization, as if there were an initialization of a static
        field. This suggests that "linkage" of the method (i.e.,
        computation of a function-like entity representing the body)
        occurs at class initialization.</div>
      <div class=""><br class="">
      </div>
      <div class="">3) Or, also suggested above: the evaluation occurs
        in a constructor, again as if a (in this case, instance) field
        were initialized with the expression.</div>
      <div class=""><br class="">
      </div>
      <div class="">4) The evaluation occurs after the constructor has
        completed, making all fields—including those initialized in the
        constructor—available.</div>
      <div class=""><br class="">
      </div>
      <div class="">5) The evaluation occurs just before first method
        invocation.</div>
      <div class=""><br class="">
      </div>
      <div class="">6) There is no "linkage" step, the method reference
        is re-computed on every invocation. Method parameters are in
        scope. This is the "syntactic sugar" approach, and the one Kevin
        is taking issue with.</div>
      <div class=""><br class="">
      </div>
      - 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 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>
    </blockquote>
    <br>
    In existing SAM conversion, we're willing to treat `Foo::bar` as
    either a static method or a bound instance method (as long as we can
    disambiguate.)  I think what's new here is that you're saying
    there's some ambiguity between whether we should infer a functional
    interface solely from the method arguments and return, or whether
    (for an instance method) we should be willing to consider the
    receiver as an extra parameter.  The latter would enable a category
    of extension-method-like use cases, where we'd have static methods
    which take a leading pseudo-receiver, designed for use as
    "injectable behavior"?  And of course doing so would expand the
    territory where the compiler couldn't pick an overload, since we
    historically did overload selection _after_ the SAM type was known. 
    This would requiring doing it against both interpretations, and
    hoping exactly one answer pops up.  <br>
    <br>
    <blockquote type="cite"
      cite="mid:7F5E0D67-0A18-47E0-9767-D474BA4E52D7@oracle.com">
      <div class=""><span class="Apple-tab-span" style="white-space:pre">     </span>void
        altMethod2() = this::method; // legal?</div>
    </blockquote>
    <br>
    If we're allowing an instance field as a receiver, its a little
    weird not to allow `this`, since `this` has basically the same
    degree of constancy as a final instance field.  <br>
    <br>
    <blockquote type="cite"
      cite="mid:7F5E0D67-0A18-47E0-9767-D474BA4E52D7@oracle.com">
      <div class="">- Delegation typically depends on an instance field
        provided as a constructor parameter, which won't work with
        (1)-(3), and if the delegation target is meant to be mutable,
        won't work with (4)-(5) either.</div>
      <div class=""><br class="">
      </div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre">     </span>Foo
        target;</div>
      <div class="">        int m1() = target::m1;</div>
      <div class=""><span class="Apple-tab-span" style="white-space:pre">     </span>int
        m2() = target::m2;</div>
      <div class=""><br class="">
      </div>
      <div class="">- Ideally, we would not like to further complicate
        the class/instance initialization story by adding new execution
        timing, as in (4) or (5). What Brian's story ((2) and (3)) has
        going for it is that we already have the infrastructure to
        describe the timing of these evaluations.</div>
      <div class=""><br class="">
      </div>
      <div class="">- We can simplify things considerably by prohibiting
        the expression form—must use Type::name. Effectively, (1) but
        without support for constant expressions. That means giving up
        on some use cases.</div>
      <div class=""><br class="">
      </div>
    </blockquote>
    <br>
    In any case, an effective simplification that includes the desired
    use cases and stays within the intendd intuition would be to only
    allow bound method refs when the receiver is a compile-time constant
    or a final field of the current class (or possibly `this`.)  <br>
    <br>
    <br>
  </body>
</html>