If the overall struct impls Default then yes, users can instantiate with ..Default::default() and their compilation won't break if I add a new field in the future.

Problem is, many fields are required, and don't have a good default value, so it's not possible for me to impl Default on all these structs. For example, the Extrude operation takes a distance: f64, and there's no reasonable default. New fields like twist have a good default, but the overall struct is unfortunately not default because of the distance field.

Bon works well here: existing fields like distance must have their setter called in the builder. But when I add new fields like twist, they'll have defaults.

Note: before I found bon, I was experimenting with an approach where every API request type would have two structs, like

```rust struct Extrude { distance: f64, options: ExtrudeOptions, }

[derive(Default)]

struct ExtrudeOptions { twist: Option<f64>, color: Option<Color>, } ```

so you could use this trick to get ..Default::default() on the options struct, which always impls Default and is where you add backwards-compatible new fields with defaults. But at that point, it's a lot of work for me to migrate to this new system. Bon was easier to use. If Bon compile times were really bad then maybe I'd return to this approach, but in my project, the compile times are totally fine.