I think we have a problem here because we can't use macros in the same compilation unit they are defined in. But we want to use the macro in the implementation of ZLayer.reloadable in zio and the macro itself depends on ScopedRef in zio.

Also the Scala 3 macro implementation uses experimental features and so cannot be used from code that is not marked as experimental.

Okay this is ready to go. The last commit shows ServiceReloader is working but we need to move it out of ZIO Core so that it doesn't depend on a macro defined in the same compilation unit. Opened a PR to ZIO Config to do that. Once we merge this I can update that to depend on a snapshot version of ZIO and we can merge that in. I think there is a little more iterating we can do on naming but would like to do that afterwards.

ZIO Config may be a really weird place to put this. Maybe we should introduce zio-macros here in core and we can have a one-import zio.macros._ that add all sort of extension methods that use macros, such as reloadable?

If ZIO comes to use macros more and more, this will be a common problem. And then ZIO Config can depend on zio-macros in order to add a hook that ties in reloading with config somehow.

What do you think?

An additional question, should we deprecate zio.Reloadable in favor of ZLayer#reloadable or does it have its own purpose?

Added a final touch to ServiceProxy to reflect its changed relationship with ServiceReloader. https://github.com/adamgfraser/zio/pull/13

@jdegoes I don't think we can do that because the macro needs to use ZIO data types, in particular ScopedRef. So reloadable can be somewhere other than ZIO Config but it needs to be something that is downstream of ZIO.

@adamgfraser Right, I imagined zio-macros being a new top-level project in this repository, which depends on core, and the user would add that project to their dependency.

@guersam

An additional question, should we deprecate zio.Reloadable in favor of ZLayer#reloadable or does it have its own purpose?

I think it could be considered deprecated after these changes because it forces you to go through get, which is not a pleasant user experience. However, for backward compat reasons we can't remove it anytime soon.

@jdegoes Yes we could do that. It is a bit odd because the functionality that it actually exposes would just be this reloadable operator but I guess you could think of it as "macro powered functionality provided by ZIO" so sure.

Yes we could do that. It is a bit odd because the functionality that it actually exposes would just be this reloadable operator but I guess you could think of it as "macro powered functionality provided by ZIO" so sure.

I can go either way. But I think if we're going to have more things like this, then it may make sense to have a project that contains them all, because that could improve discovery versus pushing "macro core" functionality into different projects across the ZIO ecosystem.

An example is RPC: it would be nice to have some functionality in ZIO that lets you easily do RPC with a ZIO service. It requires similar macros to here. It could be added as an extension method on ZLayer, e.g. ZLayer.gRPC[MyService].

@adamgfraser Take your pick on where to put that, I'm good either way.

👍

Maybe I missed the context, but doesn't zio-macros already exist in this repo?

@guersam It does. Right now it just contains the macros for generating service accessors. So it goes back to the idea that it becomes a little bit of a hodge hodge of somewhat unrelated functionality that is connected by the "how" versus the "what" but maybe that is the best we can do.

Anyway, will certainly make it easier to iterate on this if we are doing in one project.

I think this is ready to go now.

Does documentation exist about this new feature?

@khajavi Can you add?