Custom struct definition about rust-derive-builder HOT 4 CLOSED

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.

from rust-derive-builder.

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.

from rust-derive-builder.

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.

from rust-derive-builder.

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

from rust-derive-builder.