auto-application-summary.md

References

• Scala Contributors thread.

• Dotty issue: Weak eta-expansion.

• Martin's comment on the issue above.

Comments

• One comment to the effect that the motivation doesn't actually provide any motivating reasons.

  Commenter is pointed to the Dotty issue referenced above. The issue is a request to make eta expansion more uniform and predictable, and is addressed in Martin's comment linked to above. This proposal would appear to be a corrolary of of that comment.

• Some questions about parentheses and implicit argument lists.

  Resolution from Sebastiane: implicit argument application syntax unaffected by this proposal.

• A request for clarification about Java/Scala 2/3 mixed overrides, given the Java exception.

  Resolution from Martin: "As long as there is a Scala-2 or Java version in the set of overridden variants, the rule is relaxed"

• Some discussion of the use of "()" to indicate effects.

• Comment about interaction with type parameter lists, eg. Promise[Unit] vs. Promise[Unit]().

• Comment about interaction with methods returning values with an apply method. How does a programmer tell whether the following are equivalent or not?

  f()()
  f.apply().apply()
  f().apply()

• Counter proposal from Rex following from the above,

  1. Empty parameter lists, whether implicit or explicit, whether zero-parameter or filled completely with default parameters, may be elided. This matches what you’re allowed to do with overriding vs overloading anyway at the JVM level.

  2. Ambiguous parses are forbidden at the use-site. If foo() may be elided to foo, then if its return value has an apply method, that apply method cannot be called using foo().

  3. .() is another synonym for .apply(), so you can compactly disambiguate parses.

• Comment from Gabriele,

  I’m very much in favor of the spirit of this change, but a bit worried about the actual result.

  The idea is to normalize things, which makes total sense, but after this change we end up with more inconsistencies than before, due to the backward compatibility towards Scala 2.

• Interaction with nullary constructors. Currently class Foo is interpreted as class Foo(). Mutatis mutandis for case class apply methods.