Welcome to bon Discussions!

[Veetaha]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask any questions you may have, even simple ones.
• Share ideas, and provide feedback on the API, docs, etc.

---

My immediate plan for bon's close future is to make it less magical by removing the automatic into conversions rules, which is going to require a new major release. According to #15 (comment) if you want to automatically add into conversions, you'll be able to use #[builder(on(type_pattern, into))]. See details in the linked issue comment.

I wonder what people think about this design and this change overall. Does this fit your use cases, or should the existing rules for auto into conversions still exist but under smth like #[builder(auto_into)]? As for me the #[builder(on(String, into))], looks easier to understand even though a bit more verbose.

[mahmoud-moursy]

If you ask me, it would make sense for the conversions to be directly above the field they are altering.

#[builder]
pub struct Sprinkles {
    #[with(String, into)] // Function accepts the String type, calls String::into during assignment.
    colour: Option<String>,
    description: Option<String> // This is not impacted by the pattern 👍🏼
}

P.S, super cool library, and one that I unfortunately found 700+ lines of builders (+ documenting said builders) too late 😭

[Veetaha]

Thank you for the feedback! The example you provided will look like this in bon 2.0. In addition to #[builder(on(type_pattern, into))] at the top of the struct or fn, you can use #[builder(into)] on top of the individual members:

#[builder]
pub struct Sprinkles {
    #[builder(into)]
    colour: Option<String>,
    
    description: Option<String> // This is not impacted by the pattern 👍🏼
}

Sprinkles::builder()
    // The setter accepts `impl Into<String>`, so it's possible to pass a `&str`
    .colour("yellow")
    // The setter accepts only `String`
    .description("brrr".to_owned())
    .build();
    
// For optional fields, there is also a `maybe_`-prefixed setter generated that accepts `Option<_>`
Sprinkles::builder()
    // The setter accepts `Option<impl Into<String>>`, so it's possible to pass an `Option<&str>`
    .maybe_colour(Some("yellow"))
    // The setter accepts only `Option<String>`
    .maybe_description(Some("brrr".to_owned()))
    .build();

Using the type pattern as suggested with(type_pattern, into) on the member level isn't possible. bon doesn't claim that it knows the meaning of generic parameters of types, because, for example, it can't tell the difference between a Box<T> and a Vec<T> and what setters it should generate for them if T was selected for an into conversion. However, it treats Option<T> specially, and it knows that #[builder(into)] on Option<T> requires generating two setters (one accepts T, the other accepts Option<T>), where T may additionally be converted via Into.