Vitalii Kryvenko

> The issue you mentioned about overwritable is exactly what I meant Yeah, now I see, I somehow missed that point initially 😳, sorry for that. > I got the...

@dj8yfo could you share an example where `overwritable` is critical in your case?

@XBagon could you share some example code for your use case? Maybe defining a separate builder wrapper based on function with the defaults would fit your use case: ```rust #[bon::builder(finish_fn...

Do you think there is unnecessary cloning that can be avoided? If you are cloning the builder to create a new object that is composed of the values stored in...

To simplify things, just imagine that your object consists of a single string field, and you are creating 100 objects that need to use the same string value, or maybe...

> Maybe we need to extend inline_attribute_width (https://github.com/rust-lang/rustfmt/issues/3343) to also apply to function parameters? It definitely makes sense, but could it just be the default? I mean that the attribute...

I see, well, at least the default can be changed across editions, but having a config override in the meantime is reasonable

One thing. Maybe the `impl_attr/trait_attr` can be wrapped in `#[ext(impl_attr/trait_attr)]` to make it obvious which macro they come from

Hi! Thank you for creating the issue! I've been thinking of adding smth like `#[builder(must_use/explicit)]` (name is not settled yet) for an `Option` and `#[builder(default)]` parameters to explicitly configure that...

I re-read the issue again. I suppose in this use case `Option` is used, but no `None` default value is not implied, right? You'd like to make it genuinely required...