Restrict macro API

[adriaanm]

Only the simplest blackbox macros. Other applications should be subsumed by direct language support, if sufficiently proven:

• deriving
• hlists (use case: type safe mappings)

Develop good tooling support for codegen to subsume more complicated examples.

[SethTisue]

note that compiler plugins still exist, for people who realllllly want to do something arbitrary

[ritschwumm]

how about lenses, prisms, and coproducts?

[Ichoran]

Can a whitebox macro compiler plugin exist and work properly? If not, can the hooks be altered so a compiler plugin could provide whitebox macro capability?

[SethTisue]

@ritschwumm what about them? (offhand, it sounds like this might be covered under “deriving”?)

[jvican]

Can a whitebox macro compiler plugin exist and work properly? If not, can the hooks be altered so a compiler plugin could provide whitebox macro capability?

You can already do this with the current scala reflect. The whole macro infrastructure is pluggable and can be modified by any compiler plugin. But you need to know your fair amount of magic to be able to pull it off.

The only problem is that if another plugin does it, they're not composable.

[ritschwumm]

@SethTisue if they are covered, i'm fine with it. these (and source location) are the only things i use macros for in lots of places so it would be sad if i couldn't have them any more.

[nafg]

Speaking of which (source location, and making macro usages language features), it would be great if source location would be in the standard library, that way e.g. Future could use them to give better "stack traces"

[nafg]

Another suggestion that someone made that can help reduce the need for whitebox macros, is to have an API for macros to add metadata to trees that another macro can later consume

[adriaanm]

See also https://gist.github.com/odersky/f91362f6d9c58cc1db53f3f443311140

[DavidDudson]

Please see scalameta/scalameta#1182

I will be prototyping a scalameta based implementation of a code generator, to replace blackbox macro annotations and possibly some whitebox annotations.

The first implementation will be extremely basic, only allowing "extensions" to existing objects/traits/classes. This first implementation will also allow companion objects to be populated. The push to do this is mostly based around deriving typeclasses for AST nodes.

[ghik]

What exactly would be covered by "deriving"?
Obviously, it would include ADT-based deriving (case classes and sealed hierarchies). But IMHO it's also important give macros ability to materialize implementations of traits, which now requires introspection of trait methods and usually implicit searches for some typeclass instances on parameter types and return types.

[SethTisue]

out of scope for Scala 2. design discussions and implementation changes around this are continuing in Scala 3.