Skip to content
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

Closed
adriaanm opened this issue Mar 2, 2017 · 8 comments
Closed

Scalafix for migrating from 2.12 to 2.13 #327

adriaanm opened this issue Mar 2, 2017 · 8 comments

Comments

@adriaanm
Copy link
Contributor

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
Copy link

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
Copy link
Contributor Author

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
Copy link

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
Copy link
Member

See scala/scala3#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
Copy link

Sciss commented Dec 20, 2017

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

@sjrd
Copy link
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
Copy link

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 :)

@dwijnand
Copy link
Member

No need for an over-arching ticket on this anymore. scala-rewrites is a thing (and published!) and we can and will add things when they come up.

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

No branches or pull requests

7 participants