Custom struct definition

[colin-kiegel]

derive_builder could skip the struct definition and leave that to the user. It would then only generate the setters.

Possible Use Cases

• de/serialization of the builder struct or other complex derives - as an alternative to extending custom derives Add derives on derived FooBuilder struct #43 further (cc @TedDriggs).
• additional fields (and logic) which can not be derived directly from the target struct

Limitations / Drawbacks

• the user would need to exactly match the signature and error messages will most likely be not very helpful due to lacking span information, like "some type was not as expected .. ok, which one?". But on the other hand it's really just wrapping everything in an Option.
• it would be very unusual, or even surprising, to have a #[derive(...)] struct A generate impls on a struct B which is defined manually

Example

/// Derive builder, but skip the struct definition.
#[derive(Builder)]
#[builder(custom="ConfigBuilder")]
pub struct Config {
    pub appliance: Appliance,
    pub manual_limit: Option<usize>,
}

/// Manual implementation of the builder struct with `serde` derive
#[derive(Serde)]
pub struct ConfigBuilder {
    appliance: Option<Appliance>,

    #[serde(default, rename = "limit")]
    manual_limit: Option<Option<usize>>,
}

[TedDriggs]

Maybe this should be a separate derive(...) trait that goes on the handcrafted Builder struct? Something like #[derive(Setter)]? The downside then is that it's weird to have the #[builder(...)] attributes take effect on something that isn't a builder.

[colin-kiegel]

Hm, if we put the derive on the builder struct, I'd expect that most, if not all, attributes would require a different interpretation (e.g. skip, name`). This could nearly double our amount of testcases. That would be the main problem with that IMO.

[TedDriggs]

Similar to @faern's comment here on #67, having to write the struct definition manually (and keep all fields and docs in sync) would lose a lot of the value of having the builder. That sort of setter generation could be done without proc macros.

To me, the benefit of proc macros is not just LOC saved, it's time saved keeping names in sync, and time saved reading code because boilerplate isn't presented.

[TedDriggs]

I don't see this happening; closing the issue to maintain repo hygiene.