Const fn + proc macros

In terms of "same crate" macros, there was a proposal to use the same package for proc macros to eliminate separate *_derive crates, and build them the same way is:

Of course that's orthogonal to the security issue.


We could have the proc macros compile to wasm if a specific flag is specified (--wasm-macros?) . Then, all "unimplemened" functions in std would raise a special type of panic. IDEs could then pass --wasm-macros by default, and if the build fails because of an unimplemened wasm std function - prompt the user for permissions (perhaps listing the dependency ancestry of the crate whose compilation failed). If a more sophisticated sandbox is implemented (for example, allowing fs read access to the workspace), the same fallback strategy can still be used.

How well this can work depends on how many popular crates need resources outside of the sandbox. But I think that this helps deal with the issue of left-pad needing network access.


I don't think const fns can adequately replace proc macros. You may, for example, want to write part of the project in a DSL that would be transpiled into rust and have that part in separate files, which would require you to have access to file IO.

As I've mentioned a couple of times now, you can still do that via include_bytes! and include_str!

That's probably not a good idea, if you have to parse a lot of stuff. Though I'll admit I can't imagine a case where the developer would need to parse a large number of files before the software can be compiled. Still, since this does not solve the problem, it seems like a half-measure.

Expanding proc macros is pretty important for IDEs to be able to comprehend code. I'd argue that there are a lot more crates that rely on proc macros than they do generating code.


For what it's worth, many of the most-used libraries on have build scripts, including:

  • log
  • syn
  • libc
  • proc-macro2
  • serde
  • num-traits

Some relatively self-contained crates can be checked without running any build scripts, but I expect that a very large proportion of Rust projects depend on one of these, or on some other crate with a build script.

Notably, almost all crates that use proc macros have syn and/or proc-macro2 in their dependency graphs, which means they also depend indirectly on build scripts, at least for now.

1 Like

As it were, none of those crates (at least in their current form) would be helpful in the context of a const fn macro system as they are not implemented in terms of const fn.

I think that the goal is to minimize the proc macros and scripts that need to be audited. An entire tree of crates depending on lets say serde doesn't imply you need to look for compile time shenanigans in those crates if they don't use either proc macros or


Well, scratch that. Someone has already squatted that syntax.