I'd like to propose an improvement to the vergen API. It currently uses derive_builder to generate builders for various config structs. As a replacement, I propose using the bon crate.
Motivation
The problem with the builders generated by derive_builder are the following:
The build() methods of the builders return a Result, which usually requires the users to call unwrap() on it or somehow else get rid of the error, which is an annoyance. In contrast, bon generates fully compile-time-checked builders. Forgetting to set a field triggers a compile error with a readable error message.
derive_builder performs no checks for unintentional overwrites, while bon validates that you don't accidentally set the same field twice at compile time.
derive_builder doesn't generate a T::builder() method, instead, it requires the users to use TBuilder::default() to create the builder.
bon generates more ergonomic API that allows evolving it without breaking changes by default (See the compatibility page for all the possible ways to evolve your builder API in backwards-compatible way).
A comparison table between builder crates can be seen on this page
Would you be interested in this change? I understand that this will require a major release, so I understand if you'd like to push back on this, or postpone doing it until any other reasons for the major release arise.
In any case I can submit a PR from my side if you think it's fine to do it.
Hi, thank you for the awesome crate :heart:
I'd like to propose an improvement to the
vergenAPI. It currently usesderive_builderto generate builders for various config structs. As a replacement, I propose using theboncrate.Motivation
The problem with the builders generated by
derive_builderare the following:build()methods of the builders return aResult, which usually requires the users to callunwrap()on it or somehow else get rid of the error, which is an annoyance. In contrast,bongenerates fully compile-time-checked builders. Forgetting to set a field triggers a compile error with a readable error message.derive_builderperforms no checks for unintentional overwrites, whilebonvalidates that you don't accidentally set the same field twice at compile time.derive_builderdoesn't generate aT::builder()method, instead, it requires the users to useTBuilder::default()to create the builder.bongenerates more ergonomic API that allows evolving it without breaking changes by default (See the compatibility page for all the possible ways to evolve your builder API in backwards-compatible way).bonallows for greater flexibility by allowing you to generate a builder from a function or an associated method. It's even possible to switch betweenderive(Builder)and#[builder]on the method namednewwithout breaking changes.A comparison table between builder crates can be seen on this page
Would you be interested in this change? I understand that this will require a major release, so I understand if you'd like to push back on this, or postpone doing it until any other reasons for the major release arise.
In any case I can submit a PR from my side if you think it's fine to do it.