<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:CAGKkBksaw_3k7V-SjXqVCDFvp_82mHtX5gmRUpx40QFA+XCioQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>Can the expression before the :: refer to any method
            parameters? Of course, it would still expect to pass those
            parameters into the method, so it's <i>weird</i> to have
            the same parameter used in both ways, but does it make sense
            to forbid it?</div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, it makes sense to forbid.  Here's why.  <br>
    <br>
    The framing of<br>
    <br>
        method declaration = behavior literal<br>
    <br>
    is meant to suggest that the thing on the RHS can be computed ONCE,
    and that's the "body" of the method.  Therefore, it should only be
    computable based on what is known in the context of the method
    (static state for static methods, instance state for instance
    method.)  It is not merely a shorthand for "take the method ref,
    turn it into a lambda, and then turn the body of that lambda into a
    method body."  <br>
    <br>
    So the thing on the left of the :: must be something that could be,
    say, the RHS of a field initializer of the appropriate static-ness. 
    <br>
    <br>
    <blockquote type="cite">Now we want to introduce a second way to use
      method references, where that creation/evaluation distinction
      doesn't exist. </blockquote>
    <br>
    Same distinction.  You can think of the creation as happening in
    <init> / <clinit>.  <br>
    <br>
    Now, a fair question is: when should we evaluate that LHS?  And, is
    it an error or warning if that LHS is, for example, a nonfinal
    field?  Good question!  Thanks for bringing this up.  <br>
    <br>
    <blockquote type="cite">Finally, to my earlier screed about the
      trade-offs of "multiple ways to do the same thing" I want to add a
      nice (very paraphrased) point that was made on reddit by a
      now-deleted account. (Thanks, mystery person.) Offering users a
      choice between two ways to do the same thing isn't <i>just</i>
      offering them a choice. It's also burdening them with having to
      read and maintain code that made each of those choices, for
      whatever reasons that may be unknowable now. </blockquote>
    <br>
    Yes, this is a valid concern.  It will spur the usual "when should I
    use an anonymous class vs named class" FAQs, style guide wars,
    etc.   FWIW, the C# folks went through this, there was the usual
    noise at the beginning, but after the dust settled, the concise
    method bodies (the arrow form, they don't have the stronger form)
    has become a fairly popular feature.  <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>