Multiple parameter lists in Rust - rust

Question

I've just started learning Rust, and I wonder how best to translate the pattern of multiple parameter lists.
In Scala, I can define functions taking multiple parameter lists as follows:
def add(n1: Int)(n2: Int) = n1 + n2
This can be used, for example, for function specialisation:
val incrementer = add(1)
val three = incrementer(2)
val four = incrementer(three)
One of my favourite uses of this feature is incrementally constructing immutable data structures. For example, where the initial caller might not know all of the required fields, so they can fill some of them, get back a closure taking the rest of the fields, and then pass that along for someone else to fill in the rest, completing construction.
I tried to implement this partial construction pattern in Rust:
#[derive(Debug)]
#[non_exhaustive]
pub struct Name<'a> {
pub first: &'a str,
pub last: &'a str,
}
impl<'a> Name<'a> {
pub fn new(first: &'a str, last: &'a str) -> Result<Self, &'static str> {
if first.len() > 0 && last.len() > 0 {
return Ok(Self { first, last });
}
return Err("first and last must not be empty");
}
pub fn first(first: &'a str) -> impl Fn(&'a str) -> (Result<Name, &'a str>) {
|last| Name::new(first, last)
}
}
But it's extremely verbose, and it seems like there should be a much easier way (imagine there were 5 fields, I'd have to write 5 functions).
In essence I would like something like this (pseudo-Rust):
pub fn first(first: &'a str)(last: &'a str) -> Result<Name, &'static str> {
Name::new(first, last)
}
let takes_last = first("John")
let name = takes_last("Smith").unwrap()
What is the best way to have this pattern in Rust?

Answer 1

As Chayim said in a comment you did the currying part the best way possible, of course in Rust you'd usually just define the function taking all parameters, if you want to partially apply a function just use a closure at the call site:
fn add(a: i32, b: i32) -> i32 {
a + b
}
let incrementer = |b| add(1, b);
let three = incrementer(2)
let four = incrementer(three)

Answer 2

One of my favourite uses of this feature is incrementally constructing immutable data structures.
Very well. Rust's ownership rules and type system can be quite awesome for this. Consider your toy example. Here would be one way to implement:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5f823b81c3b2ca2d01e1ffb0d23aff72
struct NameBuilder {
first: Option<String>,
last: Option<String>,
}
struct Name {
first: String,
last: String,
}
impl NameBuilder {
fn new() -> Self {
NameBuilder {
first: None,
last: None,
}
}
fn with_first(mut self, first: String) -> Result<Self, &'static str> {
if first.len() == 0 {
Err("First name cannot be empty")
} else {
self.first = Some(first);
Ok(self)
}
}
fn with_last(mut self, last: String) -> Result<NameBuilder, &'static str> {
if last.len() == 0 {
Err("Last name cannot be empty")
} else {
self.last = Some(last);
Ok(self)
}
}
fn to_name(self) -> Result<Name, &'static str> {
Ok(Name {
first: self.first.ok_or("Must provide a first name!")?,
last: self.last.ok_or("Must provide a last name!")?,
})
}
}
fn main() -> Result<(), &'static str> {
let name_builder = NameBuilder::new();
assert!(name_builder.to_name().is_err());
let name_builder = NameBuilder::new()
.with_first("Homer".to_string())?
.with_last("Simpson".to_string())?;
let name = name_builder.to_name()?;
assert_eq!(name.first, "Homer");
assert_eq!(name.last, "Simpson");
Ok(())
}
This is obviously overkill for what you're doing in your example but can work really nice in situations where there are lots of parameters but where for any given concrete use case you'd only explicitly set a few of them and use default values for the rest.
An added benefit is that you can freely choose the order in which you build it.
In my example I opted for String rather than &'a str mostly so I don't have to type so many awkward &''s :p
NOTE: Even though the with_first method takes in mut self as argument, we still are dealing with an essentially immutable data structure, because we're just consuming self (i.e. taking ownership). Basically, there's no way that someone would hold a reference and then be surprised by us setting the first name to something else, because you can't move self while someone is still borrowing it.
This is of course not the only way to make a fluent interface. You could also think of a purely functional approach where data is immutable and you don't consume self. Then we're entering "persistent data structures" territory, e.g. https://github.com/orium/rpds