You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
frees-rpc will adopt the new generation of Scala Macros in the Freestyle ecosystem. This new version of the scala macros will be supported natively by the compiler in 2.13, under the scalac option -Ymacro-annotations, thanks to scala/scala#6606.
As you probably know, frees-rpc is currently depending on frees-core for defining the tagless final algebras, so we are suggesting two steps work to achieve this migration.
First, in order to parallelize the work, we need to decouple temporarily frees-rpc from frees-core. The reason would be just to minimize the potential blockers from the migration in frees-core side, which presumably would be bigger, so we could migrate Freestyle RPC faster and independently from the core. As you can imagine, we want frees-core back to frees-rpc as soon as both are inline in terms of binary compatibility (it could be considered the third stage).
As part of the second step, we'll do the migration itself, where the RPC @service macro annotation will be migrated to use the new generation of Scala Macros.
The Freestyle Maintainers team hope this makes sense and want to say that any kind of feedback is very welcomed :)
frees-rpc
will adopt the new generation of Scala Macros in the Freestyle ecosystem. This new version of the scala macros will be supported natively by the compiler in 2.13, under thescalac
option-Ymacro-annotations
, thanks to scala/scala#6606.However, the migration of the current scalameta macros (no longer under development and won't support
2.13.x
) to the new Scala Macros can be huge, mainly taking into account both https://github.com/frees-io/freestyle and https://github.com/frees-io/freestyle-rpc.As you probably know,
frees-rpc
is currently depending onfrees-core
for defining the tagless final algebras, so we are suggesting two steps work to achieve this migration.First, in order to parallelize the work, we need to decouple temporarily
frees-rpc
fromfrees-core
. The reason would be just to minimize the potential blockers from the migration infrees-core
side, which presumably would be bigger, so we could migrate Freestyle RPC faster and independently from the core. As you can imagine, we wantfrees-core
back tofrees-rpc
as soon as both are inline in terms of binary compatibility (it could be considered the third stage).As part of the second step, we'll do the migration itself, where the RPC
@service
macro annotation will be migrated to use the new generation of Scala Macros.The Freestyle Maintainers team hope this makes sense and want to say that any kind of feedback is very welcomed :)
The text was updated successfully, but these errors were encountered: