Consuming build but by mut setters?

[VorpalBlade]

It seems #[builder(pattern = "owned")] changes the behaviour of both the build function as well as the setters. I would like to decouple that:

• I have a builder that I build in a loop parsing a section + key/value file. For this is is more convenient to have &mut setters. Additionally I'd like to stick the builder in an Option to more easily handle the case of the first section / empty file. Consuming setters are quite unwieldy in that case.
• Some of the fields are quite heavy Vecs and I won't reuse the builder for the next section (each section is a clean slate). As such I would like a consuming build to avoid clones.

The pattern looks something like this in pseudo-rust:

let mut results = vec![];
let mut builder = None
let mut buffer = String::new();

while input.read_line(&mut buffer)? > 0 {
    let line = buffer.trim();
    // Handle new section (which also has the name of the section in it)
    if let Some(stripped) = line.strip_prefix("EntryThatIndicatesNewSection: ") {
        if let Some(inner) = builder {
            results.push(inner.build());
        }
        builder = Some(Builder::new());
        builder.as_mut().unwrap().name(stripped)
    } else if let Some(stripped) = line.strip_prefix("OtherEntry: ") {
        // Handle other fields, some are mandatory, some are optional (have defaults on builder)
        builder.as_mut().unwrap().other_entry(stripped);
    } else if let Some(stripped) = line.strip_prefix("AnotherEntry: ") {
        // ...
    }
    buffer.clear();
}

// Handle final entry
if let Some(inner) = builder {
    results.push(inner.build());
}

This is leaving out proper error handling etc for clarity, but it is there in the real thing.

[VorpalBlade]

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

[TedDriggs]

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.

[TedDriggs]

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.

[TedDriggs]

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.