[Pre-RFC] named arguments

[Yato]

This feature hasn’t even been accepted, let alone implemented.

[mikhail-krainik]

struct foo { x: i32 }
fn foo(pub x: i32) {}

fn main() {
    foo{x: 1};
    foo(x = 1);
}

[mikhail-krainik]

One of the point use = instead : to avoid confusing with named arguments.

fn quadratic(pub a: i32 = 0, pub b: i32 = 0, pub c: i32 = 0) -> Polynomial { 
    // ... 
}

// call as

quadratic(a = 0, b = 0, c = 0);

[soc]

Now that the thread as been resurrected, a few notes:

Scala language faces this problem with the @deprecatedName I’ve shown above:

def inc(x: Int, @deprecatedName('y) n: Int): Int = x + n

Since I worked a lot on the implementation of various @deprecatedX annotations in Scala:

• Having some consistency in parameter names beforehand is really important. You’ll need to establish some naming convention (especially regarding hard-to-name things like the lambdas in the iter API) upfront, because changing this afterward is annoying as the name has become part of the public interface.

• Nevertheless, I think requiring pub is bad and considering that structs have already have de-facto public named arguments, it would be inconsistent.

• I consider “named parameters” with : like they are already used for field initializers in structs to be a language wart. It’s so hugely confusing to me, that I simply do not use named field initializers and go out of my way to avoid using them. Adding them to more place would simply mean that I would avoid them in more places. I think I’m not the only one who dislikes the unnecessary and confusing exception to the rule of ident: Type.

Or just = with some back compat hack in the compiler (“if a is in scope, then a = x is assignment, otherwise it is a named argument”). It’s harder to implement, but user visible syntax should be more important than implementation corner cases.

Using = for named parameters is the way to go:

Experience in Scala has shown that code using assignments within the arguments of a function call is so rare¹, that in the case of an argument name clashing with a mutable binding in scope, the code is simply rejected as ambiguous.

Most languages use = to assign a value to a named argument. If we can get away with that, it would be the best syntax IMHO. However, I think this rule would cause a lot of confusion! Consider:

In Rust, I would simply declare that code like a = 5 within an argument list is always treated as a named parameter (the special allowance of Scala only complaining if the binding in scope is mutable has not been worth the cost), and assignments can be expressed with {a = b}. Scala’s rules in this regard are a case of trying to make everyone happy, but pleasing no one.

Should named arguments be reorderable at call-site?

I would not do this. It simply lacks any benefit and hugely increases the complexity – especially if people want to mix positional and named arguments. Scala devs still receive complaints about code where users expect that their particular mix of positional/named is accepted, but isn’t – simply because the implementation trying to match named/positional arguments to the parameter list is too complex already.

In general, if this proposal was resurrected, it would be necessary to also change the field initialization syntax for structs, and deprecate : in favor of = (which would be an improvement in itself). Otherwise you would have two different syntax variations doing the same thing, increasing the confusion.

---

¹ It would basically require a generic argument type without any constraints, such that the generic type could be inferred as Unit, the result type of assignments in Scala.

[Centril]

I would not do this. It simply lacks any benefit and hugely increases the complexity – especially if people want to mix positional and named arguments. Scala devs still receive complaints about code where users expect that their particular mix of positional/named is accepted, but isn’t – simply because the implementation trying to match named/positional arguments to the parameter list is too complex already.

We could simply not have named parameters and actually pass a structural record (which is at a different type) and so it would be natural to reorder because that’s how structural records work (and structs…): e.g. foo({ x: 1, y: true }).

[samsieber]

FWIW, I had been working on a proc-macro to allow named & default parameters to be used. I have a general approach in mind that should allow it to work with generics in bare functions, methods in impl blocks and trait methods. I haven’t gotten around to documenting though. And I haven’t worked on it for several months.

The basic approach though is to generate a builder struct at a location relative to the function, and create-able through a nice named function (for top level functions, it’s implemented as a method in a module with the same name as the function, for a impl block methods and trait methods, it’ll be implemented as another method, with the name based on the function name). Then it provides a macro that translates a named syntax into builder calls, and then unpacks the builder values into the positional function call. And this is doable without requiring the end user of the methods to import anything extra (relative to the normal positional syntax).

It should emFWIW, I had been working on a proc-macro to allow named & default parameters to be used. I have a general approach in mind that should allow it to work with generics in bare functions, methods in impl blocks and trait methods. I haven’t gotten around to documenting though. And I haven’t worked on it for several months.

The basic approach though is to generate a builder struct at a location relative to the function, and create-able through a nice named function (for top level functions, it’s implemented as a method in a module with the same name as the function, for a impl block methods and trait methods, it’ll be implemented as another method, with the name based on the function name). Then it provides a macro that translates a named syntax into builder calls, and then unpacks the builder values into the positional function call. And this is doable without requiring the end user of the methods to import anything extra (relative to the normal positional syntax).

It should be able to enable the following calling convention:

• {} is used to surround named arguments
• The named arguments must come after the positional arguments
• => in the named argument area
• Something akin to struct sugar - {a => a} can be replaced by {a,}

I’d be happy to outline the plan better if anybody wants to pick it up and get it more implemented - currently the macro only works for bare methods without generics.

https://crates.io/crates/rubber_duck

---

Heck, if anybody to make a macro of this, but wanted to take a different approach to how the final syntax looks, or different call semantics, I’m more than willing to talk about approaches of how to implement it with proc macros (proc macros aren’t really a strength of mine, but I have spent some time trying to figure out how to abuse them for named/called syntax in a way that doesn’t require nightly).

[Nemo157]

Nevertheless, I think requiring pub is bad and considering that structs have already have de-facto public named arguments, it would be inconsistent.

Unless you’re referring to something different than what I think you’re referring to, structs require you to explicitly note their fields as pub for external consumers to be able to use their name. It seems fully consistent to me that you would have to explicitly mark parameters as pub to allow them to be used as named arguments.

I have encountered issues in the past where a Python package was intended to be a drop-in replacement for another package, but a third-party package was using named argument syntax to call the functions and they hadn’t kept identical parameter names between the packages. Hopefully being explicit about whether the parameter name is part of the public API would avoid issues like that.

[nakacristo]

I do not quite understand why it is proposed to use foo({ x: 1, y: true }) instead of just foo{ x: 1, y: true }. That is, without parens. I mean, this is what it is done with enum’s variants. Would removing the parens break something in this context?

[mbrubeck]

That would create an ambiguity between a function call and a struct literal.

[Centril]

I do not quite understand why it is proposed to use foo({ x: 1, y: true }) instead of just foo{ x: 1, y: true } .

Because a structural record literal expression would be { f0: x0, f1: x1, ... } and function application is foo(arg). There’s no special logic here – merely the composition of two orthogonal concepts. You could also write:

type MyRecord = { x: u8, y: bool };
let arg: MyRecord = { x: 1, y: true };
foo(arg);

One might imagine papering over the ( ) but I think that’s not worth the special case for such a small gain in ergonomics.

[scottmcm]

That would create an ambiguity between a function call and a struct literal.

I think that’s the same situation as with function calls and tuple structs (foo(4) and Foo(4)), which apparently is fine, so I don’t think there’s actually a problem there.

[cuviper]

AIUI, the situation with tuple structs is that struct Foo(i32) actually does create both a type and a function named Foo. So are you suggesting record structs should do this too, or just that it’s syntactically OK for struct/call ambiguity to exist?

[scottmcm]

So are you suggesting record structs should do this too

I was thinking that if the solution worked for parens it could work for braces too. I don’t know if it’s the way we should go.

[lihzhang]

Yes, this is much better. Too much pub is quite ugly to look at.

fn get(url url: String, by timeout: u32, a a: i32, b b: i32, c c: i32){}
get(url: "https://", by: 32, a: 0, b: 0, c: 0);

is nicer than

fn get(pub url: String, pub timeout: u32, pub a: i32, pub b: i32, pub c: i32){}
get(url: "https://", timeout: 32, a: 0, b: 0, c: 0);

[lihzhang]

Hi, thanks for the proposal. I think using too much pub is quite ugly. Instead of:

fn new_window(pub title: &str, pub point: Point, pub width: u32, pub height: u32)

I like the swift way:

fn new_window(with title: &str, on point: Point, width width: u32, height height: u32)

Thank you.

[matt1985]

pub looks better than repeating identifiers like width width and height height,and reads better due to highlighting.

I think pub should be used whenever the internal names match the external names,to avoid repeating the same identifier twice,only separated by spaces.Then if someone wants to change the internal name they can remove pub and add the new name after the old one.

One example of renaming the internal name:

before:

fn new_window(with title: &str, on point: Point, pub width: u32, pub height: u32)

after:

fn new_window(with title: &str, on point: Point, width w: u32, height h: u32)

Alternatively,we could just have a convention of not repeating the external name with the internal name.

[ssokolow]

Alternatively,we could just have a convention of not repeating the external name with the internal name.

That would be more consistent with the existing ergomics optimization for struct initializers:

let new_window = Window { with: title, on: point, width, height };

…and I really need to re-read this thread. I can’t remember what’s wrong with the Python approach of sacrificing the ability to have different external and internal names in the name of more readable function signatures.

[matt1985]

What I meant was that (as an alternative) we could require external and internal names when using named parameters,and avoid repeating the same identifier for the external and internal names in the function definition by convention instead of by using pub.

The 4 possibilities for how to declare named parameters that I can see (ignoring structs) are :

1 repeating the name:

fn new(width width: u32, heigth height: u32)

2 using pub

fn new(pub width: u32, pub height: u32)

3 using underscore

fn new(_ width: u32, _ height: u32)

4 a convention of not repeating internal and external names

fn new(width w: u32, height h: u32)

All of these would be the same to the caller:

let dimension=Dimension::new(width:10,height:20);

[ssokolow]

Ahh. My bad. I thought you meant making this valid…

fn new_window(with title: &str, on point: Point, width: u32, height: u32)

…and making it a convention to use the same names for internal and external.

Having read far enough back up, I’ve now managed to remind myself why my approach wasn’t an option.

I have encountered issues in the past where a Python package was intended to be a drop-in replacement for another package, but a third-party package was using named argument syntax to call the functions and they hadn’t kept identical parameter names between the packages. Hopefully being explicit about whether the parameter name is part of the public API would avoid issues like that.

[dhm]

There is still the issue of destructuring pattern matching in functions args, for instance:

#[derive(Default)]
struct Interval { start: usize, end: usize }

impl Interval {
    fn width (
      Interval { start, end }: Interval,
    ) -> usize
    {
        end - start
    }
}

fn main ()
{
    let empty = Interval::
        default();
    Interval::width(empty);
}

Both this and the swift notation can be unified by using the @ sigil:

struct Interval { start: usize, end: usize }

impl Interval {
    fn width (
      // public_name @ binding: ty
      interval @ Interval { start, end }: Interval,
    ) -> usize
    {
        end - start
    }
}

fn main ()
{
    let empty = Interval::
        default();
    Interval::width(interval: empty);
    // or even
    Interval::width(interval@ empty); // solving the parsing ambiguity issue
}

For basic cases

fn foo (x @ x: usize);

some form of shorthand could be used, such as _@ to avoid repetition.