Discussion: Functions with many parameters

[willow385]

Requesting a design pattern for functions that take lots of parameters. For example this way:

fn foo(parameter_0: type, parameter_1: type, parameter_2: type, parameter_3: type, parameter_4: type, parameter_5: type, parameter_6: type) -> type {
    // function body
}

is a way that I think should be an anti-pattern because it's too wide. I prefer things to be less than 80 chars wide.

[twe4ked]

My first thought would be, would it make sense for the parameters to be part of a struct that you construct and pass in? It would depend on what the actual parameters represent of course.

Another option could potentially be the builder pattern. Something like this:

foo()
    .parameter_0(1)
    .parameter_1(2)
    .parameter_2(3)
    .parameter_3(4)
    .parameter_4(5)
    .parameter_5(6)
    .parameter_6(7)
    .build();

EDIT: See #64 for reasons against builder patterns for some use cases.

[burdges]

pub struct DoSomething<..> { ..paramaters.. }
impl<..> DoSomething<..> {
    pub fn go(self) { ... }
}

And choose the parameter names well, so that you can maximize field puns.

If you're okay with nightly then #![feature(unboxed_closures)] and #![feature(fn_traits)] let you write DoSomething { .. }() but imho that's kinda a poor reason for going to nightly.

[longfellowone]

My first thought would be, would it make sense for the parameters to be part of a struct that you construct and pass in? It would depend on what the actual parameters represent of course.

Another option could potentially be the builder pattern. Something like this:

foo()
    .parameter_0(1)
    .parameter_1(2)
    .parameter_2(3)
    .parameter_3(4)
    .parameter_4(5)
    .parameter_5(6)
    .parameter_6(7)
    .build();

EDIT: See #64 for reasons against builder patterns for some use cases.

And how would you deal with mandatory parameters?

[twe4ked]

And how would you deal with mandatory parameters?

I don't think I'd use it in that case.

[pickfire]

@longfellowone Do you have a required flow of the parameters?

Then there could be multiple structs (like a state machine) to ensure them have each mandatory parameter. Like most of the http crates that we have, it is required to have a url before sending.

[MarcoIeni]

And how would you deal with mandatory parameters?

foo("mandatory1", "mandatory2")
    .parameter_0(1)
    .parameter_1(2)
    .parameter_2(3)
    .parameter_3(4)
    .parameter_4(5)
    .parameter_5(6)
    .parameter_6(7)
    .build();

[MarcoIeni]

I am thinking about how to solve this issue.
Maybe we can have an anti-pattern called "Too Many Arguments In Functions"?
It could explain all the approaches proposed in this issue.

[longfellowone]

And how would you deal with mandatory parameters?

foo("mandatory1", "mandatory2")
    .parameter_0(1)
    .parameter_1(2)
    .parameter_2(3)
    .parameter_3(4)
    .parameter_4(5)
    .parameter_5(6)
    .parameter_6(7)
    .build();

What I have is a mathematical calculation that requires about 7 mandatory parameters that have no reasonable defaults. And 5 parameters that are optional

[MarcoIeni]

Put those 7 parameters in a struct and give the struct to foo

[willow385]

Here's another idea:

fn foo(
    parameter_0: type,
    parameter_1: type,
    parameter_2: type,
    parameter_3: type,
    parameter_4: type,
    parameter_5: type,
    parameter_6: type
) -> type {
    // function body
}

that's what I've been doing in the years since I opened this issue discussion :)

[oiwn]

rustfmt doing that automatically.

[simonsan]

Some thoughts:

1. First, I'm unsure if having that many arguments to a function could be considered a code smell in itself. As in: "maybe this function/method is doing too much?"
2. Second, an alternative to the builder pattern could be to use structs here:

pub struct FooDescriptor {
    parameter_0: type,
    parameter_1: type,
    parameter_2: Option<type>,
    parameter_3: type,
    parameter_4: type,
    parameter_5: type,
    parameter_6: Option<type>,
}

impl Default for FooDescriptor {
  // default()
}

fn foo(FooDescriptor) -> type {
   // function body
}

fn main() {
  let _ = foo(FooDescriptor::default());
}

That would make it easy to use optional arguments, have the arguments in one place, and would make it possible to define default parameters.

Examples:

• https://docs.rs/wgpu/latest/wgpu/struct.RenderPipelineDescriptor.html
• https://github.com/agausmann/global-clock/blob/cc9af2e255e3d5aa46ba05047efa079b6117ef82/src/globe.rs#L94-L303