Thanks, @lrytz! 🍻

LGTM -- let's come back in 2.12.x and disable 0-ary eta expansion under -Xsource:2.13

is this release-notable, or a bit too obscure for that?

i think we could add it. it's not that adding this one causes the release notes to overflow, it's more that they are already so long that it doesn't matter anymore :)

I ran into this when upgrading play-twirl in the community build. The warning asks me, "Did you intend to write foo()?" But that's the wrong suggestion; what I want in my case is foo _. Perhaps the message should offer both alternatives?

also, should this PR have included a spec update (to 6.26.2)?

What should we update about the spec? We don't usually include notes on deprecation there, but maybe we should? Regarding the error message, the assumption in swapping the order of eta-expansion and empty-arg-list-application is that the latter is far more common than the former. Thus, the message shouldn't have to mention the former (if it's relevant enough to mention, maybe we shouldn't change the behavior?)

6.26.2 says eta expansion comes before empty application. it's a chain of "Otherwise," clauses, and empty application is last in the chain. I have not followed this whole thing in detail, but I thought the whole point of SI-7187 was to change the order in 6.26.2.

You understand correctly, except that the actual change is deferred until
2.13 :-) for now we're just warning
On Fri, Sep 2, 2016 at 20:03 Seth Tisue [email protected] wrote:

6.26.2 says eta expansion comes before empty application. it's a chain of
"Otherwise," clauses, and empty application is last in the chain. I have
not followed this whole thing in detail, but my understanding is that the
whole point of SI-7187 was to change the order in 6.26.2.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5327 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFjy1zqm6W07YPxSorNnMXa1SuG0cQlks5qmGTogaJpZM4JhEGX
.

ah. so SI-7187 shouldn't have been closed in JIRA, then?

Yep, reopened.

Given this, shouldn't I be getting a deprecation warning for the following code on Scala 2.12.0?

package object mypackage {
  def render() = {}
  val handler: Function0[Any] = render _
}

I see with -Xprint:typer this becomes {(() => package.this.render())}

I arrived here by way of #4822 (comment) in trying to understand why the code above is fine but using eta-expansion with other SAM-convertible types gives a compiler error due to type mismatch (scala-js/scala-js#2656). I see the release note

Note that SAM conversion only applies to lambda expressions, not to arbitrary expressions with Scala FunctionN types

However, I would think that irrespective of this item and the note:

Eta-expansion (conversion of a method to a function value) of zero-args methods has been deprecated, as this can lead to surprising behavior

No, render _ is a method value, not eta-expansion -- that would simply be render. Eta expansion refers to the equivalence between an expression of function type that's not a function literal, and the function literal that applies that expression to the expected arguments. For the 1-argument case, eta-expansion turns e into x => e(x).

To elaborate a bit, because this is pretty confusing in the spec. The intent of the warning is to act only on implicit eta-expansion, not the explicit kind that is triggered by method value syntax.

Method values are specified here: http://www.scala-lang.org/files/archive/spec/2.12/06-expressions.html#method-values:

The expression e _ is well-formed if e is of method type or if e is a call-by-name parameter. If e is a method with parameters, e _ represents e converted to a function type by eta expansion.

Note that this means that e _ cannot have a method type, and is thus not subject to eta-expansion (it is explicit notation for triggering eta-expansion).

On eta-expansion:

6.26.5 Eta Expansion

Eta-expansion converts an expression of method type to an equivalent expression of function type.

Personally, I would prefer to deprecate method value syntax in favor of writing out the function literal. Underscore already means too many things.

Personally, I would prefer to deprecate method value syntax in favor of writing out the function literal. Underscore already means too many things

that's now scala/scala-dev#273