{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicxei3zb2fgxxe52goodpo2acwhconvrjkzgm2ortfokctfxfndde",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mk2cdqjrj2a2"
  },
  "path": "/t/way-to-make-a-configuration-struct-stable-across-versions/24187#post_3",
  "publishedAt": "2026-04-22T00:16:22.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "It seems like it goes by several names. Those docs call it functional updates, RFC 2008 calls it functional record updates, and I've seen \"spread\" a lot. I'm going with FRU I guess.\n\nSo, first, not sure if there was a misunderstanding, but yep, that is the point: `non_exhaustive` does not work for this, so I imagined an alternative that would. The hypothetical `#[non_exhaustive(pub)]` (or whatever other syntax would be better) would mean \"you must assume this struct can have more fields, **but** all of those fields will be public\", and so external code would be able to instantiate the type, but only using FRU. That would be sort of like a \"new feature in concert with `non_exhaustive`\", but also not entirely new. I think it would fit into this option mentioned in that RFC:\n\n>   * Extend `#[non_exhaustive]` with arguments in order to specify the desired behavior\n>\n\n\nSecond, I gave it more thought, and I actually found a workaround. As far as I can tell, it's surprisingly perfect, but it's a bit hacky and generates a warning.\n\n\n    #[derive(Default)]\n    pub(crate) struct NonExhaustiveMarker;\n\n    #[derive(Default)]\n    pub struct Config {\n    \tpub message: String,\n    \t// ...\n    \t#[allow(private_interfaces)]\n    \tpub non_exhaustive_marker: NonExhaustiveMarker,\n    }\n\n\nDue to the private type, you are not allowed to set `non_exhaustive_marker` from outside the crate, and you cannot mention it or interact with it at all, not even indirectly. However, since Config is public and all of its fields are public, you are allowed to construct it as long as you use FRU. Unless there is a flaw I missed, this is the exact desired behavior (although implementing it is still quite awkward compared to a simple attribute).",
  "title": "Way to make a configuration struct stable across versions?"
}