`given` initializer with side-effects is not invoked by `summon`

[armanbilge]

Compiler version

3.4.0-RC1-bin-20231223-938d405-NIGHTLY

Minimized code

//> using scala 3.4.0-RC1-bin-20231223-938d405-NIGHTLY

class Foo {
  inline def bar(x: String) = x + "bar"
}
object Foo {
  given Foo = {
    println("gimme")
    new Foo
  }
  // implicit def foo: Foo = {
  //   println("foops")
  //   new Foo
  // }
}

class Bar {
  def baz() = {
    val foobar = summon[Foo].bar("foo")
    println(foobar)
  }
}

Output

/*
 * Decompiled with CFR 0.151.
 */
import scala.Predef$;

public class Bar {
    public void baz() {
        String foobar = "foobar";
        Predef$.MODULE$.println(foobar);
    }
}

Expectation

If we replace given with implicit def foo:

/*
 * Decompiled with CFR 0.151.
 */
import scala.Predef$;

public class Bar {
    public void baz() {
        Foo x$proxy1 = Foo$.MODULE$.foo();
        String foobar = "foobar";
        Predef$.MODULE$.println(foobar);
    }
}

[erikerlandson]

In the particular case where a typeclass has inline methods, and no internal state or side-effects, I do like the current behavior of eliding any reference to it in the compiled output.

[hamzaremmal]

Minimisation :

object Foo:
  println("side-effect")
  inline def foo(x : String) = x + "bar"

@main def run = 
  val foobar = Foo.foo("foo")
  println(foobar)

if we change Foo from an object to a class, then we have the side effect.

[jducoeur]

That still seems intuitively correct to me -- since foo() is inlined, and doesn't reference its parent object, there isn't any reason for that parent to be initialized. The containing object is essentially just a logical module, not meaningfully a runtime object.

By contrast, when you're replacing it with a class, you are presumably explicitly instantiating (and thus initializing) the class before calling foo(), right?

[erikerlandson]

The original reproducer from @armanbilge seems slightly different - the implicit function that creates the Foo object has a side effect. The side effect is not attached to the class, or object.

[som-snytt]

It's always worked like this.

scala> object X { ???; final val x = 42 }
object X

scala> def f = X.x
def f: Int

scala> f
val res0: Int = 42

scala> X
scala.NotImplementedError: an implementation is missing
  at scala.Predef$.$qmark$qmark$qmark(Predef.scala:344)
  ... 33 elided

also compare

scala> trait T { ???; final val x = 42 }
trait T

scala> null.asInstanceOf[T].x
java.lang.NullPointerException: Cannot invoke "T.x()" because "null" is null
  ... 30 elided

scala> (null: T).x
val res3: Int = 42

[erikerlandson]

Are constructs like given Foo = ... always compiled as objects, when they are summoned, even if they have some kind of type parameter? I think of something like given Foo[X] = ... as behaving like a function whenever it is summoned, but is that true?

And how does that compare with the older implicit def getFoo[X]: Foo[X] = ..., in terms of how that is compiled when it is summoned? I think of implicit def and given as behaving the same at the point of summoning, but are they?

[odersky]

Parameterless givens produce lazy vals, parameterized ones produce defs.

So if you need the side effect you should add a dummy type parameter [X]. But I that's really a code smell. Generally, givens with side effects are a bad abuse of the language.