Description
We've discussed this in meetings and the proposal lays out several options, but I didn't see a tracking bug. Filing one now. Options from the proposal:
-
Don't allow macro code to mutate global state at all. This is probably
overly-restrictive, and may be hard to enforce. There are legitimate use
cases for this like like usingpackage:logging
. -
Run each macro application in a completely new isolate. Each application
has its own independent global mutable state. This is permissive in macros
while keeping them isolated, but may be slow. -
Reset all static state between macro application executions. If this is
feasible to implement and fast enough, it could work. -
Document that mutating global state is a bad practice, but don't block it.
Give no guarantees around static state persistence between macro
applications.In practice, most macros won't access any global state, so this is harmless.
But if macros do exploit this (deliberately or inadvertently) then it could
force implementations to be stuck with a specific execution order in order
to not break existing code. This is the easiest and fastest solution, but
the least safe.