Default arguments and keyword arguments

[tj]

I didn't see any issues for keyword arguments, any plans for this in the future?

---

NOTE: The bug tracker is not the place to have a design discussion. Please direct all design discussion to the etherpad (https://pad.riseup.net/p/hvbg6dQQnEe7) or create a bikeshedding page on the wiki.

Etherpads:

• discussion: https://etherpad.mozilla.org/CQEDa85jLX
• draft: https://etherpad.mozilla.org/78FA1bozLd

[bstrie]

There have been no plans for it, though nobody has yet voiced any opposition. I've been thinking about this issue for a long time, and it basically boils down to a request for default arguments. I suppose it would look something like:

fn foo(bar: int, qux=2: int, ham=0: uint) { ... }

Which could then be called as foo(1), foo(1, 3), foo(1, ham=4), foo(6, 7, 8), etc.

EDIT: Please see huonw's proposed syntax below, which looks much better and more uniform with the current declaration syntax.

[huonw]

Triage 2013-08-05: no progress (that I know of), although it'd still be neat; maybe the declaration syntax could look like

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

where the RHS is any constant expr (i.e. things that are valid in a static declaration).

[dobkeratops]

IMO these are really useful, even the C++ system of default arguments where you can only fall back to defaults for trailing unspecified arguemnts would be great... cuts down on the number of alternate named function variants whilst not being as complex as overloading .. being able to declare those in structs and enum variants aswell would be great.
Perhaps this simpler subset of the required behaviour could be implemented before there is consensus on how/if to call named keyword parameters ... it would get the internals ready ?

would it be viable/useful to implement as expressions ...in terms of earlier specified arguments & generic type parameters (eg.. ability to lookup a zero:: , or write things like slice(&self, start:uint,end:uint=self.len()) /* "foobarbaz".slice(6) == "baz" .. or create_window(parent,x,y,width:uint=parent.width()/4,height:uint=(width_161)/100) /_ default is golden-ratio shaped windows, and 1/4 screen width if you specify no size at all.. */ .... or does that just sound like a recipe for code bloat..

c++ style defaults would preclude haskell-like partial functoin-application, but i heard that was unlikely to go in?

[bstrie]

Here's another idea for default arguments. Rather than allowing arguments to be completely elided, we allow arguments for which a default exists to be invoked with a _.

So given @huonw's lovely example of:

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

...we could invoke this as foo(1, 2, None), foo(1, _, Some(1)), foo(1, _, _), etc.

However, this idea wouldn't really provide any benefits to adopting keyword arguments, given that it's still strictly positional.

[bstrie]

Changing title to "Default arguments and keyword arguments".

[dobkeratops]

not implemented, but i tried adding to the ast & parser; https://github.com/dobkeratops/rust/compare/default_args, is this the right way to go about it ? (Option@expr .. it'll need contstraints on what the expr can be ? )
dipping my toes into the water to experiment with this feature.
i'd be keen on this to increase the subset of C++ api's that could be translated, and they're definitely something i miss from C++, and the named keyword feature would be awesome beyond what c++ does.
It seemed simple and logical to go with the second suggested declaration syntax

[huonw]

@dobkeratops that looks good (although the type Default = Option<@expr> is probably unnecessary).

The constraints on the expr go in rustc::middle::check_const; you'll have to add a function like check_fn that checks each arg. (Also, presumably there should be a check that default args only appear at the end; and I guess there'll need to be something in the type-checker rustc::middle::typeck, and in trans too.)

[dobkeratops]

Ok the field is named so thats un-necasery annotation.
Thanks for the pointers on where to look, I was looking in rustc::middle::typeck::.. mod.rs (check_fn something ).

in the name of 'continuous integration' , is it worth me submitting the trivial groundwork as a pr, if I fizzle out on this maybe someone who knows the codebase better could do the other parts a lot quicker another time .
I'm always paranoid about diverging changes

Its only destructive if you definitely decide against them ?

Someone suggested this sort of thing can go in with a -Z option (..Session::debug_opts...but i didn't find these swere currently propogated everywhere (eg in the parser).

I can see you might object to the compiler parsing something it doesn't yet use, i could change it from a warning to an error perhaps...

[bstrie]

@dobkeratops Note that no official developer has commented on this yet, so it's very unlikely that any PR would be accepted. There's a lot of dicussion to be had here regarding 1) whether we want default arguments, 2) if so, what the syntax should be, and 3) whether we want keyword arguments (because the semantics that we choose for default arguments could preclude this).

[dobkeratops]

Ok well i'd guess they'd be a very low priority for a long time yet,since they dont block anything (they're certainly not top of my own wish-list).
Just thought it might be low hanging fruit, and another familiarity for C++ people ..
I suppose macros can sometimes do a similar job (and more).. and I can get into better naming habits for common/uncommon variations

[Seldaek]

I can see that named arguments aren't critical, but IMO optional args kind of are. Because in some places I think I saw a few methods with similar signatures and similar names just to offer easier interfaces when a given arg is not needed. It would suck if we end up with legacy functions like that just because a feature was missing.

[graydon]

There are a lot of subtle parts in here. Anything default arguments are an implicit form of overloading, so (I'm guessing) likely get integrated with the trait resolution algorithm and/or type inference. It might not be super difficult but it's worth careful design, and at this point I'm not sure we have the time budget for it. As a language feature I imagine it's backward compatible; as an api feature it would probably inform api design some, so represent b-c risk.

[bstrie]

@Seldaek I agree that if we want default arguments, then it's important to implement them before we commit to stdlib backwards-compatibility. However, I know of at least one language (Go) that philosophically rejects default arguments in favor of the functions-with-slightly-different-names-and-signatures approach.

However, unlike Rust, Go has a few features that make the absence of default arguments less painful. For one, they have variadic functions.[1] Secondly, you are allowed to omit fields when creating structs, which means that it's easy to pass a configuration struct to a function (the omitted fields appear to be set to compiler-specified(?) default values, rather than being something a user can customize).[2]

For the former, we might be able to get away with macro-hackery to accomplish the same result (though at laborious implementation cost). Indeed, the forthcoming replacement for fmt!() does this:

ifmt!("{foo} {1} {bar} {0}", 0, 1, foo=2, bar=3)

This is code that works today.

As for the latter, the best analogue that we have would be to use functional struct update as per the following:

struct Foo { x: int, y: int, z: int }

impl Foo {
    fn default() -> Foo {
        Foo{x: 0, y: 0, z: 0}
    }
}

fn bar(f: Foo) {
    printf!(f);
}

fn main() {
    bar(Foo{y: 5, ..Foo::default()});
}

I've seen this method offhandedly suggested in the past as a workaround for the lack of default arguments, but it's quite ungainly in practice (compare bar(Foo{y: 5, ..Foo::default()}) to bar(y=5), or my more conservative proposal of bar(_, 5, _)), and of course it forces all callers to create a struct even if they do want to pass all the arguments.

To reiterate, as one who comes from Python and Javascript I'd obviously welcome default arguments. However, I do somewhat empathize with Go's philosophy of making APIs explicit (in exchange for (potentially greatly) inflating the number of functions in the API itself).

[1] https://groups.google.com/d/msg/golang-nuts/NWMReL1HueQ/X9mdYduCOB8J

[2] http://stackoverflow.com/questions/2032149/optional-parameters

[graydon]

I should also point out that it interacts with closures and taking first class references to functions.

[Seldaek]

@bstrie thanks for the overview of Go. I agree with the point that overloading is probably a bad idea because it creates confusing APIs. Similarly the "overloaded" methods of jQuery that can take a callback in pretty much any argument you want are very weird and a pain to implement.

And I sort of agree that wrapper functions to fill in default args are not so bad in some cases. But the problem is while it saves you from some confusing cases, it does introduce a lot of boilerplate in others. One example is *::to_str_radix(num, radix). If we had optional args this could well be folded in *::to_str(num, radix = 10). I feel that in some cases the explosion of function variants really makes things less intuitive and harder to remember. Just my two cents though obviously.