Named & Default Arguments - A Review, Proposal and Macro Implementation

[scottmcm]

Then, an RFC/PR could then enable #3 the ability to call any method/function with named or unnamed calling convention. No mixing of the two would be permitted. It is either call using all parameters (except elided optional parameters) with no names in definition order or calling all parameters (except elided optionals) with named arguments (still in definition order). This again, would be a 100% backwards compatible, non-breaking change.

There’s a bunch of pain points I predict in this step particularly:

• Right now, I can change my function argument names whenever I want. This freedom is immediately lost if rust starts allowing everything to be called with named parameters. (C# has this misfeature, and I find it very frustrating there when trying to refactor things.) So I think that it’s critical that a function have chosen a nominal of some sort (perhaps annotations, perhaps a struct, …) before it can be called in a nominal way.

• What are the argument names when you call Fn* traits? What names do you use if an impl for a trait uses has different names than the trait did? What do you do if there isn’t a name because the method declaration in the trait just used _ or because this particular implementation is currently ignoring it and thus uses _ or because the pattern isn’t a simple binding, but something like fn foo([a, b, c]: [i32; 3])?

[scottmcm]

Regarding the quoted code - that’s valid syntax, but it would fail to compile because the types don’t match. Part of my proposal is that we type check blocks like {answer} to see if it should be treated as a one-field struct or as a block returning the value of answer . Granted, there are cases where this could be a breaking change - consider the situation where the return type is an impl trait, and both the struct and the single field inside it both implement the trait.

This kind of fallback tends to be particularly troublesome once the situations get more complex. Like does {{a}} mean S{a:{a}} or {S{a}}? The parser would have to generate some sort of “I’m not sure” AST that would get changed into the actual expressions after type checking, or something? It’s pretty awkward.

Also, I think the parser would rather not need to use lookahead to decide what to do on seeing a {. (Though I wish bare braces would just work…)

What I love about the struct sugar approach is that we don’t even need to consider that question - we already have structs to encode name: value pairs in the type system. And with struct sugar any improvements to structs are trivially carried over to named & default arguments for functions. We get to use structs instead of modifying the type system.

[ExpHP]

I find any “opt-out” strategy like @gbutler’s to be indefensible, especially when it changes the meaning of existing signatures, existing types (Option), and existing traits (Default).

By “changing the meaning of traits,” what I mean is, do you think f64 or Vec would impl Default if rust 1.0 had these semantics? I certainly would hope not!

---

I must thank @samsieber for this careful review and for making a proposal that takes into consideration all of these past discussions. Understanding the past is truly the only way to move forward and stop repeating history on such a hotly debated topic.

[matklad]

I’d like to through in my idea in the mix: although the shortage of ideas is not a problem here, and I really haven’t thought about relative pros and cons, I’d rather tell it (and maybe someone runs with it), rather keep it secret. It might have been proposed before, but I haven’t seen it.

We can extend arity-based overloading of this RFC to handle arbitrary named arguments. Instead of dynamically wrapping kwargs into struct/options we do static dispatch based on call syntax.

A call like xs.sort(by = |x| x.abs()) is desugard to roughly xs.sort__by__(|x| x.abs()) where desugared function named is generated from the call expression syntax. Similarly, fn sort(by = _ : impl Fn(&T) -> R) is desugard to the same name fn sort__by__(by: impl Fn(&T) -> R). Desugard names are not available directly: if you want to make a closure out of a function with keyword arguments, you have to wrap in in lambda to have param = value syntax. If you want different or optional parameters (.sort(by=), .sort(cmp=)), you’ll have to define the function several times.

Nice things about this approach is that it’s zero overhead (there’s a separate overload for each combinations of parameters) and that it doesn’t really introduce new language features (no new closure types, no new type-inference rules (desugaring is purely syntactic)).

[samsieber]

@matklad I think I understand what you’re saying - so generating one function impl per combination of named arguments from a single definition? I actually see that as being RFC 5 (after all the struct sugar stuff & inline struct declaration) if we decide that it should be a first class citizen. We could make it non-breaking by also generating a version that takes an inline struct instead of separate keywords.

[leodasvacas]

I’ve also though a lot about a design for optional arguments, and I’m of the opinion that in an initial design the default value should be None, always. Allowing custom defaults leads to difficult questions about how to write defaults and what values can be defaults, which are better left for later extensions.

Since we’re doing proposal brainstorm, I’m going to throw mine out there with little detail, just focusing on the key features. You’d declare an argument as optional by prefixing it with a keyword such as opt, as in opt y: String. You can think of opt as a binding mode, because the value is passed in as a String but bound as Option<String>. For example:

fn foo(x: i32, opt y: String) {
    let z = y.unwrap_or("a default".to_owned());
}

An optional argument will be passed as None if it’s ommited from the call site, values for optional arguments must be passed by name, as in:

foo(0, opt y = "value");

The keyword opt is used as a separator between the mandatory and optional arguments, this is a grammatical necessity to avoid ambiguities, because y is not just a name but can be a pattern, such as in:

let maybe_a_string = cli_args.value_of("arg");
foo(0, opt Some(y) = maybe_a_string);

If the pattern matches, then the matched value for y will be passed in. If the pattern is refuted, then y is passed in as None. This would be the killer feature of this proposal because it allows the caller to ergonomically pass down uncertainty about the presence of a value. This is much more expressive than a builder, with a builder this sucks as you have to write the boilerplate:

if let Some(y) = cli_args.value_of("arg") {
  Some(y) => builder.set_y(y)
}

So it’s at least 3 lines of code for each parameter.

[samsieber]

@ExpHP - I think the opt-in nature of @gbutler makes his suggested path less plausible, but it definitely could be altered to be opt in instead (the pub keyword suggestion by @Azerupi in the most recent internals thread (2016 I think) is a really elegant suggestion), while keeping the general direction (ingrained compile support instead of struct sugar) of that plan the same.

I want to mention that because I think that the two things are different concerns at play here, namely the opt-in/opt-out debate and the ingrained vs sugar debate. And I think they can mostly be decided separately.

Personally, I don’t think anything that requires opt-out for named arguments would ever make it as an RFC, though I mention that (though a little more indirectly) in my guide.

[samsieber]

@leodasvacas I think what you’re suggesting is still strictly less powerful than the builder pattern - you can do more validation inside the builder, even preseeding the builder with the correct defaults. When I saw power, I mean capability, not noise to signal ratio (e.g. boiler plate).

It definitely is shorter to write & use - and that’s the trade off - more concise, but not quite as powerful (capable).

[samsieber]

@scottmcm Dang, I forgot about that RFC. I think I came across it while doing research on this topic. I’ll have to go add it into the notes when I get time

[comex]

I don’t think it makes sense to allow omitting any function argument whose type impls Default. For example, integers impl Default, so that would mean that all integer arguments to functions become optional with a default of 0. In the majority of cases, that would make no sense.

[eaglgenes101]

Perhaps it might be a better idea to turn the need for specification in optional arguments around. Instead of being omitted entirely, placeholders are put in for arguments for which the default value should apply. A possible starting point:

In the function signature, arguments which are optional have, in their type signatures, default value assignments, which are used if the placeholder is specified. Here, the equals sign, followed by the value to use as a default, is used for this purpose, somewhat like an assignment statement.

fn increment(value: &mut i64, by: i64 = 1) {
    // If a _ is put in for by, then 1 is used for by
    *value += by
}

Then, in the caller, instead of being omitted entirely, a distinctive placeholder is used for arguments for which the default value should be used. Here, the placeholder used is _, in similar fashion to dummy values in patterns.

let mut target = 0;
increment(&mut target, _); 
// _ is a placeholder, which is filled in with 1 
// in accordance with increment's argument defaults
assert_eq!(target, 1);

If a different value is desired for an optional argument, it can be used instead of the placeholder at no additional syntactic cost.

increment(&mut target, 2); 
assert_eq!(target, 3);

It makes sense to have optional arguments after mandatory arguments here, unlike in some other ideas for optional arguments, since the placeholders make explicit which specific arguments are omitted and are intended to be filled in with defaults.

fn f(a: i64, b: i64 = 4, c: i64) { /* irrelevant */ }
// In user code...
f(3, 4); // Wrong number of arguments
f(3, 4, _); // Optional placeholder in mandatory argument position
f(3, _, 4); // Okay, equivalent to f(3, 4, 4)

Changing a mandatory argument to be optional later is also backwards compatible (but changing the default value or changing the argument back to a mandatory one is still breaking).

// Much later...
fn f(a: i64, bee: i64 = 4, c: i64 = 6) { /* irrelevant */ }
// After updates... 
f(3, 4, _); // Now this is okay, and is equivalent to f(3, 4, 6)
f(3, _, 4); // Still okay, and still equivalent to f(3, 4, 4)

[H2CO3]

1. Make the compiler able to elide Optional Parameters on Functions/Methods
2. Add annotation to opt-out of Optional Parameter elision at the definition site - Also, implement annotation or syntax for API to define a default value beyond Option<T>/None and T:Default

I’m pretty confident it should be opt-in, not opt-out. There’s a semantic difference between an optional parameter (i.e. one that doesn’t have to be supplied) and a value of type Option<T> which is a mandatory parameter. Conflating this two would not only cause confusion, but would also reduce the usefulness of default parameters because it’s possible that sometimes a default of None doesn’t make sense.

Incidentally, I don’t think defaulting to Default::default() (wow, lots of defaults in this sentence) is a good decision either. Most languages with default parameter values allow the author of a function to specify the default value explicitly only. And in Rust’s case, it could be similar:

fn transmogrify(gork: Foo = Default::default()) {
    …
}

It could be specified that the default value is the instance returned by the Default impl, but it wouldn’t be restricted to that. This has the added benefit that it syntactically disambiguates optional/default parameters (regardless of the concrete syntax used, the compiler could distinguish between the absence and presence of a default value specifier). So it probably eliminates or at least greatly reduces the needs for additional annotation noise.

Add ability to overload function/method names that require named calling convention with multiple versions with different sets of named parameters

This may or may not be a breaking change for API’s to add overloaded methods/functions depending on how this is specifically implemented.

Coming from Swift, a language with pervasive use of named parameters, I’m quite sure it would be a breaking change, and even if it weren’t, it would be a huge pain point. Swift does almost exactly the same: parameter names are part of the function name, and it causes all sorts of not-so-edge cases that are painful to learn and get over when it doesn’t compile. (At least I haven’t seen it lead to bugs.)

A side question: would this overloading work based on the function name and parameter names only?

[gbutler]

I’m pretty confident it should be opt-in, not opt-out.

Yes, I was kind of spit-balling here on the “possibilities”, but, as you and others have pointed out, this would just result in far too much magic happening for little benefit. Opt-In with Explicit Defaults is definitely the preferred solution.

I’m quite sure it would be a breaking change, and even if it weren’t, it would be a huge pain poin

I’m not sure that it would have to be a breaking change. As I mentioned, if you allow that the first definition of a function of a particular name within a scope does not include the parameter names as part of the mangled function name, then, definitions of the same function name after that in lexical order could have mangling with the names of the parameters, this would allow adding new overloads to an existing API with different named parameter sets in a 100% backwards compatible fashion (as far as I can tell).

A side question: would this overloading work based on the function name and parameter names only?

Yes, what I am proposing is overloading based on parameter names rather than types. So, you could have 2 overloads with the same types but different parameter names, but, not 2 overloads with the same set of parameter names. The parameter names become part of the mangled function/method name, so, in reality, there is no real overloading, all function/method names that the compiler ultimately deals with are unique.

[gbutler]

Right now, I can change my function argument names whenever I want.

Under my proposal, because the names of the argument become part of the “Real/Mangled” name of the function/method, you would be able to mark the original as deprecated and create the same method/function with new argument names and it would be a 100% backwards compatible API change. So, you would have the best of both worlds.

I think I’ll need to give some more details and precision to my proposal for everyone to be able to clearly see what I’m suggesting because I think many of the objections are because I haven’t been 100% clear about what I’m proposing.

[scottmcm]

Under my proposal, because the names of the argument become part of the “Real/Mangled” name of the function/method […] I think I’ll need to give some more details and precision to my proposal for everyone to be able to clearly see what I’m suggesting

Well, the problem there is that the proposal isn’t step-wise if step three is only ok because of a change that happens in step seven.

[gbutler]

he proposal isn’t step-wise if step three is only ok because of a change that happens in step seven.

Agreed, the “steps” probably need some re-jiggering.

[ehiggs]

Hi, C++ has default arguments. I was under the impression that the consensus was that it’s a failure and no one should ever use it as it makes ABI migrations extremely painful.

I could see call sites using blah(a, b, c, ...) where ... implies Default::default() for further arguments as we have in struct construction. This keeps allows an escape hatch for API compatibility but it would break ABI compatibility since it’s up to the compilation target to generate the values for the default and switching libcool.so.2.1 with libsool.so.2.2 behind the scenes would require a recompilation of the dependent libraries/executables.

Named arguments carry a similar issue. The name becomes part of the API along with the function and types in the argument list. AFAIK, only the types are part of the exported symbol (like C++).

Are ABI migrations even a concern for Rustaceans? I know Cargo doesn’t support using precompiled binaries packages, but with the size of projects growing and the unpleasant compile times of any project depending on tokio and friends, surely it /has/ to support binary packages in the near future for a limited set of targets.

[Ixrec]

Hi, C++ has default arguments. I was under the impression that the consensus was that it’s a failure and no one should ever use it as it makes ABI migrations extremely painful.

FWIW, that’s definitely not the case where I work, probably because we don’t have any reason to use dynamic linking so for all the C++ we write we only care about API and not ABI.

[ehiggs]

@lxrec, Be careful with that. See Effective C++ Item 24 and 38.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.