{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidaid45cn4vvs2gqq7kzccok2vif6sbvya7gtcfokawmhgsksurbe",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mk6te42naml2"
  },
  "path": "/t/discussion-a-perspective-on-super-let-could-a-related-lift-capability-ever-belong-in-rust-s-macro-system/24193#post_2",
  "publishedAt": "2026-04-23T18:29:06.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "docs seem to be here",
    "[1]",
    "RFC 3086 – Declarative macro metavariable expressions",
    "in this Zulip thread",
    "↩︎"
  ],
  "textContent": "Looking back at Scheme every so often when pondering the design of macro-related functionality certainly can’t hurt. For this `syntax-local-lift-expression` you’re mentioning, docs seem to be here I haven’t quite figured out yet what exactly the relevance of scoping even _is_ in the context of Scheme. I’d have to look into this more deeply to actually _understand_ how it’s used, I certainly wouldn’t mind any pointers as to where I could read some pre-existing explanations/introductions.[1]\n\nThe idea to connect the functionality for `super let` somehow more closely with macros is certainly one _I could find compelling_ myself. I don’t believe an API exclusive to _procedural macros_ would be the best approach, but that’s probably a minor discussion point & likely could be solved by also offering such functionality to declarative macros with some syntax based on RFC 3086 – Declarative macro metavariable expressions.\n\nI find the mental model of _literally_ “generating a binding in an outer scope” (hygienically), then working with a simple identifier an interesting one that I have never really considered before.\n\nRealistically, I’d believe that gaining _actual_ functionality for modifying AST outside the macro’s invocation isn’t going to happen all that easily, but one could certainly at least _pretend_ , what if it _was_? How would you use it to solve the problems `super let` wants to solve? Is this a lot easier to use? And if it _does_ seem like a conceptually or syntactically easier to work with approach, one might be able to get as close as possible _for usability_ without needing any _actual_ general mechanism to truly modify AST outside of your code.\n\nWhich probably means coming full-circle (you still need _some_ language syntax that macros actually expand to) but maybe not re-arriving _exactly_ at `super let`.\n\n* * *\n\nOne complication with super let is that there’s so many (subtle) existing properties & mechanisms for expressions to determine the (drop) scope of temporary values. If a macro receives some expression, it might want to control where temporary variables within that expressions drop - it might want to define _its own_ values that are supposed to act like temporaries, and define where those drop - it might even want to specify how the macro-call (as an expression) itself interacts with the rules of temporary lifetime extension. Only some of these use-cases can easily be re-interpreted as a simple _assignment to an identifier_ , others not so easily.\n\n* * *\n\nIf you haven’t seen those already, there are some more recent discussions / design documents around `super let` that you can find in this Zulip thread.\n\n* * *\n\n  1. I have used Racket/Scheme before; I’m not looking for a beginner tutorial or anything  ↩︎\n\n\n",
  "title": "[Discussion] A perspective on super let: could a related “lift” capability ever belong in Rust’s macro system?"
}