Hacker News Reader

Comment by aazaa | Hacker News Reader

> Since we do not have default arguments in Rust, in order to initialize such structure we would have to list all fields:

I'm surprised the article doesn't mention Default:

https://doc.rust-lang.org/std/default/trait.Default.html

It can be combined with the rest pattern to yield something very similar to the solution the author is after.

https://stackoverflow.com/questions/19650265/is-there-a-fast...

View on HN

What bugs me a bit about Rust is the lack of default parameters. Even with the Default trait, the caller still has to write a bit of boilerplate ( ..Default::default()).

The caller needs to know that the input struct implements Default.

And you would need one input struct per function (if default values differ).

Are there better ways or is it planned to introduce something like default parameters?

> Are there better ways

It's a question of taste, but the builder pattern can be considered a “better way”, because of how clunky the use of Default can be.

You would prefer an API with easier to read, documented builders than the ..Default::default() call.

What I dislike about the builder pattern is that it treats input not as one 'blob' of data and thus makes simple things more complicated.

I have the same feeling. I would love to know if a builder object can be zero cost and if it could actually write assembly code the same way as if we would have passed those arguments manually.

Default parameters, optional parameters, and named parameters kind of form this massive design space where they all sorta kinda influence each other, and so while there hasn't been a formal "yes" or "no" directly from the team about these features, they tend to get caught up in a combination of "there are bigger issues to worry about" along with the combinatorial explosion of truly exploring the design space, at least from what I've observed over the years.

Thanks for the insight, Steve! I'm glad the team thinks about these issues.

This solution works sometimes, but it's not great if any of the fields don't have a sensible default.

In which case they should be explicitly provided.

You end up having to do

  struct Parameters {
    non_optional_parameter_1: Foo,
    non_optional_parameter_2: Bar,
    extra_options: ParametersWithDefault,
  }

  #[derive(Default)]
  struct ParametersWithDefault {
    ...
  }

which is kind of annoying but not the end of the world.

It's a lot of small papercuts, but

    use module::{ foo, Parameters, ParametersWithDefault };

    fn bar() {
        foo(Parameters {
           non_optional_parameter_1: Foo,
           non_optional_parameter_2: Bar,
           extra_options: ParametersWithDefault {
               optional_param: Baz,
               ...Default::default(),
           }
        });
    }

is a far cry in ergonomics from:

    use module::foo;

    fn bar() {
        foo(_ {
            non_optional_parameter_1: Foo,
            non_optional_parameter_2: Bar,
            optional_param: Baz,
            ..
        });
    }

Even just having to import the extra structs (and lookup the names) is a massive pain. Especially if you need to change to use a slightly different function.

Default only assigns parameters to their default value based on their type (e.g. "0" for u8), it's not an actual implementation of actual default parameters.

More details about this and what else is lacking in Rust compared to Kotlin:

https://medium.com/@cedricbeust/what-rust-could-learn-from-k...

You can derive the Default trait (this is the most popular use case) or implement it yourself where you can have custom default values.

You can just implement the Default trait yourself and set sane defaults right? At least that’s how I use it, implement the default trait manually to easily return a initialized struct.

Yes, I was referring to when you derive the trait, I should have been more specific.

Also, this doesn't help at all for function invocation, which is still very cumbersome in Rust in the absence of default parameters, named parameters, and overloading.

Reply on news.ycombinator.com