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
I have to admit that I am not very fond of the current state of macros.
Scala 3 is getting closer and closer, which also means that the end of macros as we currently know them does too.
I currently tend to avoid all libraries using Scala 2 macros, since I cannot be sure if some of the features from these libraries will be supported in the future.
Agree, we have to be careful to not depend on a macro as an integral part of the library. But I still believe that it would be beneficial for the performance to construct parts of a VNode at compile-time. The main part is reading the list of VDomModifier grouping them by type or name and then creating maps and lists for properties, attributes, styles, hooks and children.
So, we would want a def macro that is inlined at the call-site. This is sadly not possible with scala-meta since they have pivoted to be more about tooling - they deprecated annotation macros, too (see: https://www.scala-lang.org/blog/2017/10/09/scalamacros.html).
In the end, I believe that we will have some kind of macro system in scala 3, because it is vital for many libraries we are using daily. But, of course, we do not know exactly, so a macro in outwatch should just be an addition that can be used but is not needed. It could probably even live in a separate subproject if we do not want the default apply method to do this.
No description provided.
The text was updated successfully, but these errors were encountered: