{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih6icmuldc3hwxrphnwsgf4zhs7e25abuic2xpzespoj2kx3gdxea",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mh74ycyet2f2"
  },
  "path": "/t/could-borrow-checking-with-origins-unblock-sound-specialization/24079#post_7",
  "publishedAt": "2026-03-16T13:29:22.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Serhii:\n\n> robofinch:\n>\n>> we further don't want to allow specialization on lifetimes at all.\n>\n> But is this really the case? Specializing on `'static` seems like a perfectly valid use case. `'static` is not an origin computed by the borrow checker, it's a property of the data itself. No borrow checker upgrade will change whether a string literal or an owned type is `'static`. `T: 'static` is already a bound the solver understands.\n\nBecause it would require needlessly duplicating functions for every instantiation. And it is incompatible with HRTB (`for<'a> fn(&'a ())` might need different codegen for when it is passed an `&'static ()` or a `&'notstatic ()`, but it represents only a single function pointer that needs to be valid for both lifetime instantiations)",
  "title": "Could borrow checking with origins unblock sound specialization"
}