By the way, I checked with profiling and in my case the clone calls for those Vecs do not get optimised away unfortunately.

from rust-derive-builder.

This should be straightforward to implement.

API

We'd allow setting the pattern in #[builder(build_fn(pattern = "..."))]. if present, this would override the one set at the #[builder(pattern = "...")] level; if absent, the builder-level pattern will be used.

Implementation

Options::as_build_method would be updated to use the new build_fn override when initializing BuildMethod's pattern field.

from rust-derive-builder.

Looking at this again, I'm now second-guessing my original thought on the API. It feels like it might be better for the top-level pattern field to be the one that controls the signature of the build function, while allowing the override of the setters in the #[builder(setter(pattern = "..."))] meta item at the struct level.

from rust-derive-builder.

Okay, so I think the reason this is proving more challenging than expected is that the current behavior of the pattern field is weird.

Currently, that field can be set on the struct or on a field. The strange part is how setting it on a field interacts with the build method. I don't understand the rationale behind the current design, so I'm hesitant to change it too much.

from rust-derive-builder.