Would be good to proxy val and non-ZIO-returning methods directly, rather than just abort with error.

Imagine:

trait MyService {
  val MyConstant = 4
  def square(x: Int): Int
  def effectful(x: Int): Task[Int] = ZIO.succeed(x * x)
}

For this use case, we need an unsafe way to access the underlying service, because ScopedRef#get is an effectful operation.

Possible solutions:

1. Unwrap ScopedRef#get directly using Runtime
2. Replace ScopedRef with Ref.Atomic for unsafe get, and let the caller ensure resource safety

What do you think?

It seems to me that val makes no sense, because val means the value cannot change.

So we are strictly talking about def which can return different values every time.

Rather than support this, I think maybe your existing implementation makes more sense: just provide a good error message explaining why we can only proxy ZIO-returning methods.

If val also be hotswapped, I think val also makes sense.

    test("Forwards abstract vals") {
      trait Foo { val bar: UIO[String] }
      val service1: Foo  = new Foo { val bar: UIO[String] = ZIO.succeed("zio1") }
      val service2: Foo = new Foo { val bar: UIO[String] = ZIO.succeed("zio2") }
      for {
        ref  <- ScopedRef.make[Foo](service1)
        proxy = Proxy.generate(ref)
        res1 <- proxy.bar
        _    <- ref.set(ZIO.succeed(service2))
        res2 <- proxy.bar
      } yield assertTrue(res1 == "zio1" && res2 == "zio2")
    }

As @SHSongs mentioned, forwarding ZIO vals still makes sense thanks to referential transparency.

Non-ZIO vals can cause trouble as you pointed out, even if it's concrete.

I'd suggest:

1. Forwards ZIO vals as the test case above shows
2. Reject non-ZIO abstract vals
3. Warns about concrete non-ZIO vals that it might cause unexpected behavior

I would be inclined to just reject all methods not returning a ZIO value. The layer constructing a service could provide different implementation of the interface when it is reloaded so I don't think it is safe to expose values that aren't ZIO workflows. Exposing all interfaces as ZIO workflows is idiomatic anyway and this is special functionality we are adding to improve ergonomics in common situations so I think it is fine to be opinionated.

Should be @experimental due to Symbol.newClass and ClassDef.apply.

It breaks cross compilation currently. @SHSongs

There will probably be a better place than zio.Proxy.

Let's call it zio.ServiceProxy because it's specifically a type of proxy for service interfaces (also the name Proxy is so generic, it will lead to clashes in other name spaces).

I think this is correct behavior for things like constants. Could be extra strict and require they be final for bulletproof semantics.