New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scalafix for migrating from 2.12 to 2.13 #327

Open
adriaanm opened this Issue Mar 2, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@adriaanm
Member

adriaanm commented Mar 2, 2017

So that we can deprecate the following language features / stdlib members:

  • procedure syntax
  • implicit val/def without complete signature
  • any2stringAdd
  • (offer refactoring to annotate non-private members)

@adriaanm adriaanm added this to the 2.13 milestone Mar 2, 2017

@nafg

This comment has been minimized.

Show comment
Hide comment
@nafg

nafg Apr 19, 2017

What's the plan for implicit object X extends Y -- will that be allowed? I seem to recall it not being as good as a precise type.

nafg commented Apr 19, 2017

What's the plan for implicit object X extends Y -- will that be allowed? I seem to recall it not being as good as a precise type.

@adriaanm

This comment has been minimized.

Show comment
Hide comment
@adriaanm

adriaanm Apr 19, 2017

Member

Good question. I think these are fine because we just write their type as the corresponding singleton type without requiring further inference. This rule aims to avoid triggering inference during implicit search, which is thus always ok for objects. Will have to experiment a bit more to convince myself though :)

Member

adriaanm commented Apr 19, 2017

Good question. I think these are fine because we just write their type as the corresponding singleton type without requiring further inference. This rule aims to avoid triggering inference during implicit search, which is thus always ok for objects. Will have to experiment a bit more to convince myself though :)

@Sciss

This comment has been minimized.

Show comment
Hide comment
@Sciss

Sciss Dec 20, 2017

What's the deal with "implicit val/def without complete signature"? I have been recently following IntelliJ's advise to add return types for implicit vals, but this produces a quite unfortunate situation, illustrated by the following examples:

before

implicit val auralContext = AuralContext[S](server, scheduler)
implicit val system = InMemory()
implicit val undo = UndoManager()

after

implicit val auralContext: AuralContext[S] = AuralContext(server, scheduler)
implicit val system: InMemory = InMemory()
implicit val undo: UndoManager = UndoManager()

etc.

May I propose that a type annotation be not required if we call either new Type or call apply on the companion object such as Type()? If so, where would I discuss and eventually propose this rule?

I think that would strike a good balance between still essentially documenting the type and avoiding Java'ish DRY horror.

Sciss commented Dec 20, 2017

What's the deal with "implicit val/def without complete signature"? I have been recently following IntelliJ's advise to add return types for implicit vals, but this produces a quite unfortunate situation, illustrated by the following examples:

before

implicit val auralContext = AuralContext[S](server, scheduler)
implicit val system = InMemory()
implicit val undo = UndoManager()

after

implicit val auralContext: AuralContext[S] = AuralContext(server, scheduler)
implicit val system: InMemory = InMemory()
implicit val undo: UndoManager = UndoManager()

etc.

May I propose that a type annotation be not required if we call either new Type or call apply on the companion object such as Type()? If so, where would I discuss and eventually propose this rule?

I think that would strike a good balance between still essentially documenting the type and avoiding Java'ish DRY horror.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Dec 20, 2017

Member

See lampepfl/dotty#2879, where @smarter indicates that:

Dotty does reduce the boilerplate a bit by desugaring:

val x: Foo[Bar] = new { ... }

To:

val x: Foo[Bar] = new Foo[Bar] { ... }
Member

dwijnand commented Dec 20, 2017

See lampepfl/dotty#2879, where @smarter indicates that:

Dotty does reduce the boilerplate a bit by desugaring:

val x: Foo[Bar] = new { ... }

To:

val x: Foo[Bar] = new Foo[Bar] { ... }
@Sciss

This comment has been minimized.

Show comment
Hide comment
@Sciss

Sciss Dec 20, 2017

@dwijnand Ok, but that leaves Companion.apply which in my experience is far more common...

Sciss commented Dec 20, 2017

@dwijnand Ok, but that leaves Companion.apply which in my experience is far more common...

@sjrd

This comment has been minimized.

Show comment
Hide comment
@sjrd

sjrd Dec 20, 2017

Member

Explicit types for implicit vals should only be required for field vals. Local vals (inside defs) are allowed not to have an explicit type.

Member

sjrd commented Dec 20, 2017

Explicit types for implicit vals should only be required for field vals. Local vals (inside defs) are allowed not to have an explicit type.

@Sciss

This comment has been minimized.

Show comment
Hide comment
@Sciss

Sciss Dec 20, 2017

@sjrd thanks for the clarification; I will then petition IntelliJ to rethink their default inspection which indeed produces unneeded verbosity :)

Sciss commented Dec 20, 2017

@sjrd thanks for the clarification; I will then petition IntelliJ to rethink their default inspection which indeed produces unneeded verbosity :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment