Skip to content

Eta-expand 0-arity method if expected type is Function0#7660

Merged
adriaanm merged 3 commits intoscala:2.13.xfrom
adriaanm:eta-zero
Feb 11, 2019
Merged

Eta-expand 0-arity method if expected type is Function0#7660
adriaanm merged 3 commits intoscala:2.13.xfrom
adriaanm:eta-zero

Conversation

@adriaanm
Copy link
Contributor

@adriaanm adriaanm commented Jan 17, 2019 •
edited
Loading

Reverse course from the deprecation introduced in 2.12.

(4.3) condition for eta-expansion by -Xsource level:

  • until 2.13:
  • 2.14:
    • for arity > 0: unconditional
    • for arity == 0: a function-ish type of arity 0 is expected (including SAM)

warnings:

  • 2.12: eta-expansion of zero-arg methods was deprecated (eta expansion should not precede empty application  bug#7187)
  • 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0
    warning still available under -Xlint:eta-zero
  • 2.14: expected type is a SAM that is not annotated with @FunctionalInterface
    if it's a Java-defined interface (under -Xlint:eta-sam)

(4.2) condition for auto-application by -Xsource level:

  • until 2.14: none (assuming condition for (4.3) was not met)

  • in 3.0: meth.isJavaDefined
    TODO decide -- currently the condition is more involved to give slack to
    Scala methods overriding Java-defined ones; I think we should resolve that
    by introducing slack in overriding e.g. a Java-defined def toString()
    by a Scala-defined def toString. This also works better for dealing
    with accessors overriding Java-defined methods.

    The current strategy in methodSig is problematic:

    // Add a () parameter section if this overrides some method with () parameters
    val vparamSymssOrEmptyParamsFromOverride =

    This means an accessor that overrides a Java-defined method gets a
    MethodType instead of a NullaryMethodType, which breaks lots of
    assumptions about accessors

@scala-jenkins scala-jenkins added this to the 2.13.0-RC1 milestone Jan 17, 2019
This was referenced Jan 17, 2019
Merged
Closed
Closed
@dwijnand
Copy link
Member

dwijnand commented Jan 17, 2019

Do you need to redo #7614 too?

@adriaanm
Copy link
Contributor Author

adriaanm commented Jan 17, 2019

Yep, thanks!

@som-snytt
Copy link
Contributor

som-snytt commented Jan 17, 2019

The PR to undo is the one where -Ymoors undoes the other PRs and forks the language.

@adriaanm
Copy link
Contributor Author

adriaanm commented Jan 17, 2019

PRs to implement -Yunmoorsed welcome :-p

@jrudolph jrudolph mentioned this pull request Jan 17, 2019
Merged
@adriaanm adriaanm self-assigned this Feb 4, 2019
@adriaanm
Copy link
Contributor Author

adriaanm commented Feb 4, 2019

Interesting issues in future-spec -- the other two test fails are due to a bug this introduces under -Xsource:3.0

@adriaanm adriaanm requested a review from retronym February 5, 2019 15:27
@adriaanm

This comment has been minimized.

Sign in to view
@adriaanm adriaanm force-pushed the eta-zero branch 3 times, most recently from 8b47517 to 0da9315 Compare February 5, 2019 20:51
adriaanm
adriaanm commented Feb 6, 2019
View reviewed changes
@adriaanm adriaanm assigned retronym and unassigned adriaanm Feb 6, 2019
retronym
retronym reviewed Feb 7, 2019
View reviewed changes
retronym
retronym reviewed Feb 7, 2019
View reviewed changes
retronym
retronym reviewed Feb 7, 2019
View reviewed changes
som-snytt
som-snytt reviewed Feb 7, 2019
View reviewed changes
@SethTisue SethTisue added the release-notes worth highlighting in next release notes label Feb 7, 2019
@adriaanm
Eta-expand 0-arity method if expected type is Function0
4520117 
Reverse course from the deprecation introduced in 2.12.

(4.3) condition for eta-expansion by -Xsource level:

  - until 2.13:
    - for arity > 0: function or sam type is expected
    - for arity == 0: Function0 is expected -- SAM types do not eta-expand
      because it could be an accidental SAM scala/bug#9489
  - 2.14:
    - for arity > 0: unconditional
    - for arity == 0: a function-ish type of arity 0 is expected (including SAM)

warnings:
  - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187)
  - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0
          warning still available under -Xlint:eta-zero
  - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface`
          if it's a Java-defined interface (under `-Xlint:eta-sam`)

(4.2) condition for auto-application by -Xsource level:

  - until 2.14: none (assuming condition for (4.3) was not met)
  - in 3.0: `meth.isJavaDefined`
    TODO decide -- currently the condition is more involved to give slack to
    Scala methods overriding Java-defined ones; I think we should resolve that
    by introducing slack in overriding e.g. a Java-defined `def toString()`
    by a Scala-defined `def toString`. This also works better for dealing
    with accessors overriding Java-defined methods.

    The current strategy in methodSig is problematic:
    > // Add a () parameter section if this overrides some method with () parameters
    > val vparamSymssOrEmptyParamsFromOverride =

    This means an accessor that overrides a Java-defined method gets a
    MethodType instead of a `NullaryMethodType`, which breaks lots of
    assumptions about accessors
@adriaanm

This comment has been minimized.

Sign in to view
@adriaanm
Copy link
Contributor Author

adriaanm commented Feb 10, 2019 •
edited
Loading

I think I addressed all review comments.

@adriaanm adriaanm merged commit dbf7081 into scala:2.13.x Feb 11, 2019
@SethTisue
Copy link
Member

SethTisue commented Feb 11, 2019

@adriaanm we should un-deprecate in 2.12.9, then?

@adriaanm
Copy link
Contributor Author

adriaanm commented Feb 12, 2019

Good point: #7740

@SethTisue SethTisue mentioned this pull request Feb 16, 2019
Closed
SethTisue added a commit to scalacommunitybuild/scalaz that referenced this pull request Feb 26, 2019
@SethTisue
eta expand explicitly in one place
a39c46a 
needed in recent 2.13 nightlies because of the combination of
scala/scala#7660 and scala/scala#7263
@eed3si9n eed3si9n mentioned this pull request Jul 17, 2019
Closed
@som-snytt
Copy link
Contributor

som-snytt commented Dec 22, 2019

It warns on usual usages of varianceInType. I'm not sure if the code comment is about whether to require the annotation, or whether it's too annoying to warn.

Implicits.scala:701:78: Eta-expansion performed to meet expected type scala.tools.nsc.Variance.Extractor[Implicits.this.global.Symbol], which is SAM-equivalent to Implicits.this.global.Symbol => scala.reflect.internal.Variance,
[warn] even though trait Extractor is not annotated with `@FunctionalInterface`;
[warn] to suppress warning, add the annotation or write out the equivalent function literal.
[warn]                 val targs = solvedTypes(tvars, allUndetparams, varianceInType(wildPt), upper = false, lubDepth(tpInstantiated :: wildPt :: Nil))

eed3si9n added a commit to eed3si9n/scala that referenced this pull request Jun 2, 2020
@eed3si9n
Remove eta-expansion of SAM under -Xsource:3
f1da627 
Ref scala bug 12006

scalagh-7660 added `-Xsource:2.14` mode that eta-expands on SAM types. This confuses `URL#openStream` to be treated as SAM when `Function0[InputStream]` is expected, and get a weird error message:

       error: type mismatch;
        found   : java.io.InputStream
        required: Int
This was referenced Jun 2, 2020
Closed
Closed
@dwijnand dwijnand mentioned this pull request Jun 23, 2020
Merged
@smarter smarter mentioned this pull request Apr 22, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@som-snytt som-snytt som-snytt left review comments

@retronym retronym retronym approved these changes

@SethTisue SethTisue Awaiting requested review from SethTisue

@smarter smarter Awaiting requested review from smarter

Assignees

@retronym retronym

Labels

release-notes worth highlighting in next release notes

Projects

None yet

Milestone

2.13.0-RC1

Development

Successfully merging this pull request may close these issues.

6 participants

@adriaanm @dwijnand @som-snytt @SethTisue @retronym @scala-jenkins