During some of the discussion about the dangers of automatic proc macro expansions by IDEs I saw an interesting idea discussed which seems to solve a number of cross-cutting concerns:
What if proc macros were implemented were in terms of
Some possibilities I can see with this:
I'm sure there are gaps here people will no doubt point out, but using
const fn would seem to address the main concerns for why proc macros are separated out, namely that they could impact codegen in the crate they're used in. But what if proc macros were
const fns that could only call other
const fns defined in
std or a crate's dependencies (or potentially even the same crate, although that seems tricky)?
const fn proc macros they'd be evaluated by Miri, which at least for now heavily restricts what is possible for an attacker to do with macro expansion. For example, you could still
include_bytes! to embed a secret into compiled binary, but unless that binary were executed it couldn't automatically exfil those secrets just by an IDE performing macro expansion.
Those IDE expansions are definitely a very helpful feature to have, but per some recent demonstrations a rather scary one to enable for any project you don't trust. Perhaps a more restricted macro system could find a middle ground?