Prevent generating maybe_-prefixed method, and a way to provide the default value from within fn new

[teohhanhui]

1. I think there should be a way to prevent generating the maybe_-prefixed method, i.e. only make the call optional with no way of explicitly setting None.

2. It'd be nice to have a way to provide the default value from inside the function body of fn new, e.g.

struct TilePos {
    x: u32,
    y: u32,
}

#[bon]
impl TilePos {
    #[builder]
    fn new(x: u32, maybe_y: Option<u32>) -> Self {
        Self {
            x,
            y: y.unwrap_or_else(|| x * 2),
        }
    }
}

[Veetaha]

Hi!

(1) Could you elaborate so I better understand the motivation? Why would you like to remove the maybe_-prefixed method? In what specific use case do you think it would be excessive?

(2) It's already possible to provide the default value from inside the function body

use bon::bon;

struct TilePos {
    x: u32,
    y: u32,
}

#[bon]
impl TilePos {
    #[builder]
    fn new(x: u32, y: Option<u32>) -> Self {
        Self {
            x,
            y: y.unwrap_or_else(|| x * 2),
        }
    }
}

fn main() {
    // You can get the default value if you don't call `y/maybe_y` setters at all
    let value = TilePos::builder().x(3).build();
    assert_eq!(value.y, 6);

    // ...or if you pass `None` to `maybe_y` setter
    let value = TilePos::builder().x(3).maybe_y(None).build();
    assert_eq!(value.y, 6);
}

Alternatively, the same could be written with derive(Builder) syntax because you can access values of other members declared higher in the struct inside of the #[builder(default = ...)]. See Evaluation Context paragraph in #[builder(default)] API reference.

#[derive(bon::Builder)]
struct TilePos {
   x: u32,

   #[builder(default = x * 2)]
   y: u32,
}

fn main() {
   // You can get the default value if you don't call `y/maybe_y` setters at all
   let value = TilePos::builder().x(3).build();
   assert_eq!(value.y, 6);

   // ...or if you pass `None` to `maybe_y` setter
   let value = TilePos::builder().x(3).maybe_y(None).build();
   assert_eq!(value.y, 6);
}

[Veetaha]

Nope, unfortunately, the example you shown above doesn't compile with the following error:

`if` and `else` have incompatible types
expected struct `ExampleBuilder<example_builder::SetX>`
   found struct `ExampleBuilder<example_builder::Empty>`

This is because the builder uses a typestate to check for overwrites. It changes the type when you call a setter to make sure you don't accidentally call the setter for the same member twice.

[Veetaha]

You could theoretically disable that check with #[builder(overwritable)], in which case the example above would start compiling. Would you give up on overwrite checks in your use case to make the code shown above compile?

[Veetaha]

To be clear, I need a convincing use case example, where disabling the option_fn (i.e. maybe_ setter) obviously improves the API. You mentioned that there isn't a good name for this setter in your case and that it breaks the fluent API.

Could you show the exact code you mean in this case? I need to have that context as well, otherwise I'm not convinced. You can omit impl details or come up with the alternative example if the code in question is under NDA

[teohhanhui]

`if` and `else` have incompatible types
expected struct `ExampleBuilder<example_builder::SetX>`
   found struct `ExampleBuilder<example_builder::Empty>`

Uhh, that's unfortunate but understandable, given the whole point of the typestate pattern being used...

To be clear, I need a convincing use case example

I don't have such an example. Sorry... Just thinking ahead in terms of the API being exposed by the builder, that's all.

Especially given my impression here:

My initial impression of this library is that it seems to follow a similar philosophy as thiserror, where you can transparently switch to a manual implementation without changing the API. Is that right?

[Veetaha]

My initial impression of this library is that it seems to follow a similar philosophy as thiserror, where you can transparently switch to a manual implementation without changing the API. Is that right?

Yes, your impression is correct. The generated builder's API doesn't couple it with bon specifically, and you could theoretically replace it with a manual impl.

I'll keep this at the current state where it's not possible to disable the maybe_ setter, until I see a compelling use case for disabling it. This is to make sure users don't shoot themselves in the foot with the dynamic Option<T> handling annoyances and thinking that they could use an if {} as you shown above to workaround this (which has own nuances).

Note that it is physically possible to hide that setter anyway by making the setters private #[builder(setters(vis = ""))], and write a custom setter. It's just that I don't think anyone would ever want to do this at this point. I'm ready to be proven wrong though