Skip to content

How do we handle access to global mutable state in macros? #1917

Closed
@munificent

Description

@munificent

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:

  1. 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 using package:logging.

  2. 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.

  3. Reset all static state between macro application executions. If this is
    feasible to implement and fast enough, it could work.

  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions