Vitalii Kryvenko

Well, it can't be a cargo feature because it changes the type signature of the builder in a non-additive way (it removes some generic associated types from the builder's state...

So, you'd still like to keep the overwrites disabled? My expectation was that it wouldn't be as important since the overwrites problem doesn't happen that often, and people are used...

Well, the difference between `overwritable` and non-`overwritable` becomes visible only at a greater scale (especially in structs with 50+ fields, because the compile time complexity grows quadratically (unfortunatelly) with the...

Yeah, I see you points. Anyway, I already have this feature implemented in my branch. I'll probably just keep it disabled by default and make it available only if the...

I don't think this particular feature bears high maintenance burden. I'll just keep it experimental for 6 months, for example. And if I receive no feedback on this issue, I'll...

@MuhannadAlrusayni > I already use TypedBuilder for this Could you elaborate how you configured `TypedBuilder` to allow for overwrites? As I know, `TypedBuilder` doesn't allow calling setters repeatedly, and there...

@MuhannadAlrusayni Aha, with that `TypedBuilder` code, now it's clear. Indeed, I think this use case doesn't fit into the `overwritable` attribute. If you'd like to adapt that code to `bon`,...

@angelorendina, thank you for looking into this and considering a contribution! `overwritable` does remove the `where S: IsUnset` bound by design. Although, how do you think this can be a...

> I have a workaround that looks like this: Thank you for sharing this. Although I don't see how the example use case you shown could be nicely solved with...

@angelorendina, I've just discovered a problem in the current `#[builder(overwritable)]`, which isn't critical, but still a bit ugly. The problem is that if you call the setter several times for...