{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiexa4oyhbifk6gbylsp75oy64cv2kunlmq3c753rwlw2ie2wp4zwq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjzyc6atawb2"
  },
  "path": "/t/way-to-make-a-configuration-struct-stable-across-versions/24187#post_2",
  "publishedAt": "2026-04-21T20:22:30.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "functional update syntax.",
    "there may be invariants that need upheld which could be violated by just copying or moving the private fields.",
    "There's some related discussion in the future possibilities of the default field value RFC."
  ],
  "textContent": "It's called functional update syntax. Note that it takes an arbitrary expression and isn't limited to `Default::default()`. It's not allowed when there are private fields or when `non_exhaustive` is in effect, as there may be invariants that need upheld which could be violated by just copying or moving the private fields.\n\nIf `non_exhaustive` is not in effect and there are no private fields, you don't have to use function update syntax (if you supply all the fields), which defeats your \"add options in the future\" goal. So while I too would like to see `non_exhaustive` be applicable with privacy scopes other than just `crate`, it wouldn't actually solve your use case on its own.\n\nThis would be some new \"allow struct expression but require functional update syntax\" feature in concert with `non_exhaustive`, or perhaps \"require functional update syntax\" in combination with all public and defaulted field values, etc. There's some related discussion in the future possibilities of the default field value RFC.",
  "title": "Way to make a configuration struct stable across versions?"
}