5 ms·

It’s sad that Rust has decided to settle with the builder pattern instead of implementing named arguments.

cyber_kinetist 4y ago
Can’t you pass “argument” structs as parameters to kinda emulate the feel of named arguments (along with using the Default trait)? I use this in C++ a lot, and it seems that some Rust devs are doing this too.
- kevincox 4y ago
  You can, but it is a mouthful. Especially if you want optional arguments. foo::some_func(foo::SomeFuncArgs{ a: 8, b: Some(false), ..Default::default() }) Personally I would be really happy if `..` could default to `..Default::default()` which would make this a lot cleaner. But even then needing to name a type for the argument struct is noisy. Language-integrated keyword arguments would make this a lot cleaner: foo::some_func( a=8, b=Some(false))
  - cercatrova 4y ago
    Indeed, it's basically the same as in JS/TS where you just pass an object of key/values rather than have named arguments.
    - kevincox 4y ago
      Yes, but it is a lot cleaner there because you don't need to specify the name of the type and you don't need to do anything special for optional arguments. I wouldn't mind if it worked this way "under the hood" but syntax sugar for passing that last argument as keyword arguments would be a fantastic quality of life improvement.
  - cyber_kinetist 4y ago
    By the way, C++20 designated initializers works like a charm for this. foo::some_func({ .a = 8, .b = false }); (I view this and std::span as the only two usable features in C++20, and pretty much everything else can go to the dustbin or the drawing board.)
  - estebank 4y ago
    I'm waiting to getting some spare time to propose (not quite but very close) that in an RFC. A lot of conversation about it from a while back is available at https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-sugar-for-default-default/13234/75 https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-suga...
maxbond 4y ago
Why? The builder pattern is great.
- joseluis 4y ago
  Having both approaches available would be better IMHO. Builder pattern is very nice but I frequently miss having named arguments too. Even if macros can partially fullfill that need, it's not the same and introduces more quirks and complexity...
  - maxbond 4y ago
    Fair enough.
  - Ygg2 4y ago
    Problem with named parameters is that they make renaming function params a breaking change.
    - metaltyphoon 4y ago
      Unless the IDE doesn’t support this refactoring? It’s ridiculously easy in C# and VS or VSC.
      - setr 4y ago
        A (public) library doesn't have access to all codebases depending on it.
      - Ygg2 4y ago
        Even there changing the method param will invalidate semver specification.
- kevincox 4y ago
  It gets awkward really fast when you may need to set a value. let mut foo = build_foo() .with_a(8); if need_to_set_b { foo = foo.with_b(false); } let foo = foo.build();
davidatbu 4y ago
I'm pretty sure that there's no objection to including named arguments in Rust as of yet. It's just that no one has wanted it badly enough to write an RFC for, and implement, named arguments.

Can’t you pass “argument” structs as parameters to kinda emulate the feel of named arguments (along with using the Default trait)? I use this in C++ a lot, and it seems that some Rust devs are doing this too.

kevincox 4y ago
You can, but it is a mouthful. Especially if you want optional arguments. foo::some_func(foo::SomeFuncArgs{ a: 8, b: Some(false), ..Default::default() }) Personally I would be really happy if `..` could default to `..Default::default()` which would make this a lot cleaner. But even then needing to name a type for the argument struct is noisy. Language-integrated keyword arguments would make this a lot cleaner: foo::some_func( a=8, b=Some(false))
- cercatrova 4y ago
  Indeed, it's basically the same as in JS/TS where you just pass an object of key/values rather than have named arguments.
  - kevincox 4y ago
    Yes, but it is a lot cleaner there because you don't need to specify the name of the type and you don't need to do anything special for optional arguments. I wouldn't mind if it worked this way "under the hood" but syntax sugar for passing that last argument as keyword arguments would be a fantastic quality of life improvement.
- cyber_kinetist 4y ago
  By the way, C++20 designated initializers works like a charm for this. foo::some_func({ .a = 8, .b = false }); (I view this and std::span as the only two usable features in C++20, and pretty much everything else can go to the dustbin or the drawing board.)
- estebank 4y ago
  I'm waiting to getting some spare time to propose (not quite but very close) that in an RFC. A lot of conversation about it from a while back is available at https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-sugar-for-default-default/13234/75 https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-suga...

maxbond 4y ago

Why? The builder pattern is great.

joseluis 4y ago
Having both approaches available would be better IMHO. Builder pattern is very nice but I frequently miss having named arguments too. Even if macros can partially fullfill that need, it's not the same and introduces more quirks and complexity...
- maxbond 4y ago
  Fair enough.
- Ygg2 4y ago
  Problem with named parameters is that they make renaming function params a breaking change.
  - metaltyphoon 4y ago
    Unless the IDE doesn’t support this refactoring? It’s ridiculously easy in C# and VS or VSC.
    - setr 4y ago
      A (public) library doesn't have access to all codebases depending on it.
    - Ygg2 4y ago
      Even there changing the method param will invalidate semver specification.
kevincox 4y ago
It gets awkward really fast when you may need to set a value. let mut foo = build_foo() .with_a(8); if need_to_set_b { foo = foo.with_b(false); } let foo = foo.build();

davidatbu 4y ago

I'm pretty sure that there's no objection to including named arguments in Rust as of yet. It's just that no one has wanted it badly enough to write an RFC for, and implement, named arguments.