{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigtnnj4guoqivduyvitteh2rrnuiaoocvoqiu2ol4q6nqbauljdde",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mipkxnpfv732"
  },
  "path": "/t/why-is-rustc-bootstrap-so-actively-discouraged/24123#post_15",
  "publishedAt": "2026-04-04T11:13:25.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "breaking even when just bumping z",
    "::core::fmt::from_fn()",
    "https://releases.rs",
    "https://docs.rs/std:"
  ],
  "textContent": "The OP does correctly mention the merits of _versioned nightly_.\n\nIndeed, I do think version nightly, assuming it's interpreted as `x.y.z-nightly` in Cargo-Semver parlance (_i.e._ , breaking even when just bumping z), can be preferable to \"dated nightly\", barring patches:\n\n  * version numbers are way more memorable than arbitrary cut-off dates,\n\n  * especially when cross-referencing with stabilized APIs.\n\n_e.g._ , do I need a `feature` to use ::core::fmt::from_fn()?\n\n    * if you were using `x.y.z-nightly` versioned nightly, then you'd be able to answer this directly: since the cut-off version stabilizing it is `1.93.0` as per the docs, then on `1.92.0-nightly` or below you'd need the feature, and `1.93.0-nightly` and onwards you would not.\n\n    * but if you're using `nightly-yyyy-mm-dd`, how do you quickly answer this question for `nightly-2025-11-23` _vs._ `nightly-2025-01-03`, for instance?\n\nThe answer is that, as a first approximation, you'd need to identify the cut-off _date_ of the `1.93.0` nightly, using, for instance, https://releases.rs, from which we can observe it was December the 5th 2025 for `1.93.0`,\n\nand October the 24th for `1.92.0`; so we know that prior to `2025-10-24` it will for sure be unstable, and `2025-12-05` onwards it will be stable; but for my november date example it remains _unclear_ :\n\nSo the more accurate approach is actually to _find the stabilization PR_ and look at the merge date (not too difficult, but definitely more hassle than \"just\" going to https://releases.rs, itself more hassle than checking a version number on https://docs.rs/std:\n\nWhich gives us the date of November the 4th (for GMT+1); so `nightly-2025-11-05` and onwards ought to do it?\n\n\n\n\n**So yeah, it would be quite handy to get some form of versioned nightly.**\n\n* * *\n\nAnd it just turns out that, for now, since we don't have that in any form, the only way to hackily DIY-polyfill such a thing is through `RUSTC_BOOTSTRAP=1 +stable`.\n\nAnd this is _socially_ problematic, since it has the name `stable` in its name (it sounds like \"nightlied `stable`\" more than \"_versioned_ `nightly`\").\n\nI personally, and at work, use this in certain scenarios (whilst being willing to exceptionally use pinned nightly for a hotfix), and to great success, out of the value of versioned nightly as a concept. But it is very important to be aware of the tradeoffs and limitations that come with it.\n\n### TL,DR\n\nWe'd probably benefit from an official support of versioned nightly so as to supersede this hacky but legitimate usage of `RUSTC_BOOTSTRAP=1 +stable`.",
  "title": "Why is `RUSTC_BOOTSTRAP` so actively discouraged?"
}