Migration tool should add result types of implicit definitions

[odersky]

I noted that a lot of tests have implicit definitions such as

 implicit val hello = "hello"
 implicit def convert(x: String) = x.length

which lack an explicit result type. These are no longer valid in dotty. So it would be great if the migration tool adds the result type.

[samuelgruetter]

In a first step, I could add the result type with its full prefix (the same way as types are printed by scalac error messages). But ideally, any unnecessary prefix of the type should be omitted, no one wants to have code like

implicit val x: my.long.packagename.blah.TheType = ...

we just want

implicit val x: TheType = ...

(if TheType is visible).
There is some code in the sprinter library which attempts to strip unnecessary prefixes, but imho, that's something that the Scala compiler should provide, and also use in its error messages... Are there plans to do this in dotty? Or even Scala? Imho this would increase the readability of error messages a lot...

[retronym]

@samuelgruetter It's worse: it really ought to be _root_.my.... :)

[retronym]

Sprinter code is being migrated into Scala itself (See showCode in 2.11.0-RC1). Not sure about the plan for context-sensitive selection printing, though.

[retronym]

@odersky Do you still allow implicit objects? These can't have an ascribed type.

[DarkDimius]

There is some code in the sprinter library which attempts to strip unnecessary prefixes, but imho, that's something that the Scala compiler should provide, and also use in its error messages...

imho, verbose class names in error messages is a good thing. It's quite common to have multiple entities with same (short)name in big projects.

[xeno-by]

That's what sprinter is good at. It only strips prefixes if that leads to unambiguous names.

[odersky]

Implicit objects are allowed. They don't need an ascribed type because their expansion is automatically ascribed with a type.

[retronym]

What type is ascribed below? O$? Won't that trigger a cycle when implicit search checks O$ <:< DummyImplicit?

val x = implicitly[DummyImplicit]
implicit object O {
  val y = x
}

[odersky]

The object is expanded to

implicit val O: O$ = new O$
class O$ { this: O.type => val y = x }

[adriaanm]

Interesting, is there any special treatment necessary except for the new O$ being exempt from its self type adhering to O.type?