Implicit conversion to Dynamic should allow dynamic selection

[lego-eden]

Compiler version

Scala 3.8.0-RC1-bin-20250814-0cf7a18-NIGHTLY

Minimized code

//> using scala 3.nightly

import scala.language.implicitConversions
import scala.language.dynamics

given Conversion[Int, Int & Dynamic] = _.asInstanceOf

extension (i: Int & Dynamic)
  def selectDynamic(s: String): Unit = println(s)

@main def main =
  4.fooMember

Output

Fails to compile:

[error] value fooMember is not a member of Int
[error]   4.fooMember
[error]   ^^^^^^^^^^^

Expectation

It compiles and prints fooMember. The implicit conversion should be called and int should be converted into Int & Dynamic, which should make this work.

[som-snytt]

This falls under "chained implicits" because dynamic selection is an implicit conversion that is tried after other conversions have failed to typecheck.

Maybe dynamic selection could be made to support the extension syntax directly.

Normally, e.m(x) becomes e.applyDynamic("m")(x).

Alternatively, try extension applyDynamic(e.asInstanceOf[E & Dynamic])("m")(x).

That feature would be called dynamic extension.

[lego-eden]

So there exists an alternate way to make this compile? Do you have a short example of what you mean by dynamic extensions?

[som-snytt]

I intended to say that the compiler could be improved to support such a feature, but that would be a change to the specification.

My proposal is that the compiler could support your snippet without the conversion.

Worth adding that conversion to Dynamic also does not work in Scala 2.

Worth adding that my proposals are rarely accepted, because I like baroque mechanisms.

[lego-eden]

Should I make a draft pull request? How do I go about improving the compiler? Do i make a pre-SIP or something?

[sjrd]

This was always intended not to work. It was specifically forbidden by the original Dynamic SIP. Allowing it now would definitely need a new SIP, but I doubt it would be accepted.

[som-snytt]

Actually the SIP says

My tendency would be to go with the original proposal for now. We can always move to the alternative proposal later provided we get usecase experience that would convince us that the benefits outweigh the dangers.

Maybe Odersky is just a nice guy and this is his forbidding tone.

I think the extension definition taking Dynamic is as safe as explicitly extending it in a custom class.

In particular, there is (in supporting extension without conversion) no conversion to an arbitrary type that might accidentally (unbeknownst to the client of the type) extend Dynamic.

@lego-eden For sure, any movement would require a pre-SIP, as demonstrated recently by the thread about dedented multiline literals, which I will say could profitably be called "demented" literals.

[lego-eden]

Ok i will put some work into making a thread in scala contributors about this then