6 ms·

> 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 men

• nicoburns 5y ago
  This solution works sometimes, but it's not great if any of the fields don't have a sensible default.
  • delta1 5y ago
    In which case they should be explicitly provided.
  • khuey 5y ago
    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.
    • nicoburns 5y ago
      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.
• davidkunz 5y ago
  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?
  • Narann 5y ago
    > 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.
    • davidkunz 5y ago
      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.
      • Narann 5y ago
        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.
  • steveklabnik 5y ago
    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.
    • 5y ago
• hota_mazi 5y ago
  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-kotlin-b32ebe2da28d https://medium.com/@cedricbeust/what-rust-could-learn-from-k...
  • tristan957 5y ago
    You can derive the Default trait (this is the most popular use case) or implement it yourself where you can have custom default values.
  • slashink 5y ago
    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.
    • hota_mazi 5y ago
      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.