Interesting, i wouldn't reach for a builder pattern in the article's scenario: struct User { email: Option<String>, first_name: Option<String>,

Interesting, i wouldn't reach for a builder pattern in the article's scenario: struct User { email: Option<String>, first_name: Option<String>, last_name: Option<String> } My gut feel would have been to drop the Option<> and just have different structs with different combinations of fields as needed. E.g. You could consume an PersonName type with an EmailAddress type to produce a User type if that's what you needed.