5 ms·

If only Rust had named function parameters, you could write what is IMHO the most readable option: Span::new(days=5, hours=8, minutes=1)

DemocracyFTW2 2y ago
could you do that with `struct` / `record` fields? In JavaScript which doesn't have named function parameters either I often write functions with a single `cfg` parameter that are called like `f({ hours: 2, seconds: 53, })` which I find nice b/c it re-uses existing data structures.
- Galanwe 2y ago
  Well the beautiful thing about software engineering is that pretty much everything is possible, it essentially boils down to "but should you really"? :-)
- devanl 2y ago
  In Rust, you can't implicitly omit fields when instantiating a struct, so it would have to be a bit more verbose, explicitly using Rust's analog to the spread syntax. It would have to look something like: f({ hours: 2, seconds: 53, ..Default::default() }) The defaults could come from some value / function with a name shorter than Default::default(), but it would be less clear.
  - estebank 2y ago
    Adding support for struct default field values would allow for - leaving some mandatory fields - reduce the need for the builder pattern - enable the above to be written as f(S { hours: 2, seconds: 53, .. }) If that feature ever lands, coupled with structural/anonymous structs or struct literal inference, you're getting everything you'd want from named arguments without any of the foot guns.
    - kibwen 2y ago
      Has anyone ever proposed it? It's such a straightforward feature with such obvious semantics ("default field values are const contexts") and impossible-to-bikeshed syntax (`a: i32 = 42`) that I've been meaning to write up an RFC myself for around, oh, ten years now...
      - steveklabnik 2y ago
        nrc was poking at the problem in 2016 https://internals.rust-lang.org/t/struct-field-defaults/3412 https://internals.rust-lang.org/t/struct-field-defaults/3412 which led to this RFC https://github.com/rust-lang/rfcs/pull/1806 https://github.com/rust-lang/rfcs/pull/1806 It got postponed because it wasn't going to make it into Rust 2018: https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327922562 https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327...
        estebank 2y ago
        Last time I had this conversation[1] the main sticking point were around semantics of private fields, but I am convinced that the maximally restrictive version can be done (only pub fields can be optional) and maybe relaxed later after we get some real world experience. The other thing was about whether the default values needed to be const, but that makes sense as a restriction to me. 1: https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-sugar-for-default-default/13234/74 https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-suga...
        steveklabnik 2y ago
        Yeah makes sense! I haven’t felt the need for this feature personally, but it feels like it fits with the language pretty well to me. The big issue with default values (as far as I’m concerned) is for them to always have a default value, and this doesn’t change the opt-in nature of the concept.
        estebank 2y ago
- 4hg4ufxhy 2y ago
  Kind of inefficient. Also it's less ergonomic since every struct is it's own type, so you need to have the signature on both sides.
  - benmmurphy 2y ago
    It should compile to the same because a struct passed by value is loaded into the registers the same as method arguments.
_flux 2y ago
Yes, that could've been lended almost as-is from OCaml, in particular as Rust doesn't have partial application so optional arguments would work out-of-the-box as well.
- berkes 2y ago
  Are named arguments on the roadmap somewhere? Or is it a won't-fix?
  - _flux 2y ago
    I haven't seen anything for or against in actual roadmaps. But there is, of course, at least one pre-proposal: https://internals.rust-lang.org/t/pre-rfc-named-arguments/16413 https://internals.rust-lang.org/t/pre-rfc-named-arguments/16... It doesn't think about optional arguments (but somehow does include overloading). And a bit in a related fashion, it doesn't permit for reordering calling arguments, which I consider a downside: > Reordering named arguments when calling > No it is not possible. Just like unnamed arguments and generics, named arguments are also position-based and cannot be reordered when calling: register(name:surname:) cannot be called as register(surname:name:). > Reordering them at the definition site is an API break, just like reordering unnamed arguments or generics is an API break already. The rationale for this expressed in the comments says it's incompatible with overloading, but to me I don't see why named arguments and overloading should go hand-in-hand—or, indeed, how desirable overloading is in the first place. Or why should overloading be able to overload that kind of scenario. The other reasons for this don't seem really problems at all. > fn func2(pub name: u32, name hidden: u32) { /\* ... */ } > fn func3(name hidden1: u32, name hidden2: u32) { /* ... */ } > func2 and func3 could work in theory: named arguments as proposed in this RFC are position-based and their internal names are different: just like two arguments can have the same type without ambiguity, those functions could be allowed. Maybe there are technical reasons that are simpler when considering type compatibility between function types that have or don't have labeled arguments? Seems the proposal has misunderstood something about OCaml labeled arguments when placing it under https://internals.rust-lang.org/t/pre-rfc-named-arguments/16413#mandatory-and-ordered-named-arguments-61 https://internals.rust-lang.org/t/pre-rfc-named-arguments/16... , though. In addition the proposal doesn't seem to have a neat syntax for forwarding named parameters, like in constructing records you can just fill in a field called foo by mentioning its name by itself—or, like in OCaml you can have let foo ~bar = bar + 1 let baz ~bar = foo ~bar let main () = baz ~bar:42 If it used the .-prefix as mentioned as an idea elsewhere, then this too could be naturally expressed. Maybe there are other ideas how to go about the labeled arguments, though that one seems pretty well thought-out. One thing I've enjoyed with Python (and Mypy) is the ability to require the caller to use named arguments with the asterisk marker in the parameter list. This idea is mentioned in the proposal.
nurettin 2y ago
I'm all for named parameters. C++ is sorely lacking that feature as well. Currently using vs code with C++, I like how it handles the missing language feature by adding a grayed out parameter name before the value for function calls and initializers. Maybe there is something like that for rust.
- School-Cotton 2y ago
  Yes, editors can be configured to do the same thing for rust.
- hypeatei 2y ago
  These are called "inlay hints" and exist for most editors/languages.

DemocracyFTW2 2y ago

could you do that with `struct` / `record` fields? In JavaScript which doesn't have named function parameters either I often write functions with a single `cfg` parameter that are called like `f({ hours: 2, seconds: 53, })` which I find nice b/c it re-uses existing data structures.

Galanwe 2y ago
Well the beautiful thing about software engineering is that pretty much everything is possible, it essentially boils down to "but should you really"? :-)
devanl 2y ago
In Rust, you can't implicitly omit fields when instantiating a struct, so it would have to be a bit more verbose, explicitly using Rust's analog to the spread syntax. It would have to look something like: f({ hours: 2, seconds: 53, ..Default::default() }) The defaults could come from some value / function with a name shorter than Default::default(), but it would be less clear.
- estebank 2y ago
  Adding support for struct default field values would allow for - leaving some mandatory fields - reduce the need for the builder pattern - enable the above to be written as f(S { hours: 2, seconds: 53, .. }) If that feature ever lands, coupled with structural/anonymous structs or struct literal inference, you're getting everything you'd want from named arguments without any of the foot guns.
  - kibwen 2y ago
    Has anyone ever proposed it? It's such a straightforward feature with such obvious semantics ("default field values are const contexts") and impossible-to-bikeshed syntax (`a: i32 = 42`) that I've been meaning to write up an RFC myself for around, oh, ten years now...
    - steveklabnik 2y ago
      nrc was poking at the problem in 2016 https://internals.rust-lang.org/t/struct-field-defaults/3412 https://internals.rust-lang.org/t/struct-field-defaults/3412 which led to this RFC https://github.com/rust-lang/rfcs/pull/1806 https://github.com/rust-lang/rfcs/pull/1806 It got postponed because it wasn't going to make it into Rust 2018: https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327922562 https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327...
      - estebank 2y ago
        Last time I had this conversation[1] the main sticking point were around semantics of private fields, but I am convinced that the maximally restrictive version can be done (only pub fields can be optional) and maybe relaxed later after we get some real world experience. The other thing was about whether the default values needed to be const, but that makes sense as a restriction to me. 1: https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-sugar-for-default-default/13234/74 https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-suga...
        steveklabnik 2y ago
        Yeah makes sense! I haven’t felt the need for this feature personally, but it feels like it fits with the language pretty well to me. The big issue with default values (as far as I’m concerned) is for them to always have a default value, and this doesn’t change the opt-in nature of the concept.
        estebank 2y ago
4hg4ufxhy 2y ago
Kind of inefficient. Also it's less ergonomic since every struct is it's own type, so you need to have the signature on both sides.
- benmmurphy 2y ago
  It should compile to the same because a struct passed by value is loaded into the registers the same as method arguments.

_flux 2y ago

Yes, that could've been lended almost as-is from OCaml, in particular as Rust doesn't have partial application so optional arguments would work out-of-the-box as well.

berkes 2y ago
Are named arguments on the roadmap somewhere? Or is it a won't-fix?
- _flux 2y ago
  I haven't seen anything for or against in actual roadmaps. But there is, of course, at least one pre-proposal: https://internals.rust-lang.org/t/pre-rfc-named-arguments/16413 https://internals.rust-lang.org/t/pre-rfc-named-arguments/16... It doesn't think about optional arguments (but somehow does include overloading). And a bit in a related fashion, it doesn't permit for reordering calling arguments, which I consider a downside: > Reordering named arguments when calling > No it is not possible. Just like unnamed arguments and generics, named arguments are also position-based and cannot be reordered when calling: register(name:surname:) cannot be called as register(surname:name:). > Reordering them at the definition site is an API break, just like reordering unnamed arguments or generics is an API break already. The rationale for this expressed in the comments says it's incompatible with overloading, but to me I don't see why named arguments and overloading should go hand-in-hand—or, indeed, how desirable overloading is in the first place. Or why should overloading be able to overload that kind of scenario. The other reasons for this don't seem really problems at all. > fn func2(pub name: u32, name hidden: u32) { /\* ... */ } > fn func3(name hidden1: u32, name hidden2: u32) { /* ... */ } > func2 and func3 could work in theory: named arguments as proposed in this RFC are position-based and their internal names are different: just like two arguments can have the same type without ambiguity, those functions could be allowed. Maybe there are technical reasons that are simpler when considering type compatibility between function types that have or don't have labeled arguments? Seems the proposal has misunderstood something about OCaml labeled arguments when placing it under https://internals.rust-lang.org/t/pre-rfc-named-arguments/16413#mandatory-and-ordered-named-arguments-61 https://internals.rust-lang.org/t/pre-rfc-named-arguments/16... , though. In addition the proposal doesn't seem to have a neat syntax for forwarding named parameters, like in constructing records you can just fill in a field called foo by mentioning its name by itself—or, like in OCaml you can have let foo ~bar = bar + 1 let baz ~bar = foo ~bar let main () = baz ~bar:42 If it used the .-prefix as mentioned as an idea elsewhere, then this too could be naturally expressed. Maybe there are other ideas how to go about the labeled arguments, though that one seems pretty well thought-out. One thing I've enjoyed with Python (and Mypy) is the ability to require the caller to use named arguments with the asterisk marker in the parameter list. This idea is mentioned in the proposal.

nurettin 2y ago

I'm all for named parameters. C++ is sorely lacking that feature as well. Currently using vs code with C++, I like how it handles the missing language feature by adding a grayed out parameter name before the value for function calls and initializers. Maybe there is something like that for rust.

School-Cotton 2y ago
Yes, editors can be configured to do the same thing for rust.
hypeatei 2y ago
These are called "inlay hints" and exist for most editors/languages.