{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidctwwluce6a42354mnreiudzlwtyt45scx33qmzr5vahbuteqhfa",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjzybln55nq2"
  },
  "path": "/t/way-to-make-a-configuration-struct-stable-across-versions/24187#post_1",
  "publishedAt": "2026-04-21T19:45:37.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Here's a usage snippet for a rendering library I wrote for my own use:\n\n\n    \tlet triangle_pipeline = device.create_raster_pipeline(RasterPipelineOptions {\n    \t\tvertex_shader: Some(triangle_shader_module.get(\"vertex\")),\n    \t\tfragment_shader: Some(triangle_shader_module.get(\"fragment\")),\n    \t\t..Default::default()\n    \t})?;\n\n\nYou can see the intent: I want to pass some options to this function by name and fill the rest with defaults, and on the library side, be able to add options in the future without needing to break semver. For example, I could add more customization for blending or multisampling that I hadn't thought of in my first release. Ideally, the user would be able to create the struct, but be required to use the spread expression to account for any gaps.\n\nI thought surely I could just slap a #[non_exhaustive] onto the options struct, and that'd do the trick. But it turns out that attribute actually blocks other crates from creating it! The reason appears to be that you could add private fields... even though that would not make any sense here. The obvious fix would be if there were a #[non_exhaustive_pub] or #[non_exhaustive(pub)] variant that lifts that restriction, but there isn't currently.\n\nAlso, obviously, an alternative way to implement this would be to use a builder. The problem is that that's way too much work. A struct would be much more ergonomic, and there should be no need to create a function for each field.\n\nSo, has a #[non_exhaustive(pub)] (or another form of this functionality) ever been considered (like an RFC that I didn't find)? Or is there a better way to do this, or closely emulate it? (Of course, if I'm wrong that it is currently not possible to do this, do tell.)",
  "title": "Way to make a configuration struct stable across versions?"
}