optional parameters

[iopq]

RFC for optional parameters added to Rust functions

[huonw]

Is the trailing _ a typo?

[iopq]

yes, it's a typo

[jnicklas]

I'd like to propose an alternate syntax. How about something akin to Java's overloading?

fn concat(&self) -> String {
  self.join(self, ",")
}

fn concat(&self, sep: &str) -> String {
  ...
}

// compile error, because the first parameter's type
// doesn't match the type of `concat` already declared.
fn concat(&mut self, sep: &str) -> String {
  ...
}

// compile error, because the second parameter's type
// doesn't match the type of `concat` already declared.
fn concat(&self, number: int) -> String {
  ...
}

This feels like it has way more precedent, and it's quite clear how the syntax works, and we don't have to answer weird questions like what happens to sep inside the function body in case it is not given.

[huonw]

// doesn't match the type of to_str already declared.

s/to_str/concat/?

[jnicklas]

@huonw yes, copy-paste error, I updated the comment.

[bstrie]

I don't understand what you mean by "satisfies both traits". Rust isn't duck-typed, and therefore you only satisfy a trait if you explicitly implement it. Merely implementing a function with a compatible type signature doesn't allow you to do anything generically.

[bstrie]

@jnicklas, this is such an enormously wide-open design space that I don't want to sidetrack the comments here discussing alternatives. Note as well that this particular RFC explicitly rejects Java-style overloading. Given that people have certainly asked for overloading in the past (especially among C++ developers, our key demographic), I would suggest that you propose an entirely separate RFC if you'd like to discuss it. But if you do so, please make sure it's complete and well-considered; submit a pre-RFC to the mailing list if you'd like to solicit opinions and feedback.

[alexcrichton]

Note that there is a great deal of discussion at rust-lang/rust#6973.

I would encourage this RFC to plan for a backwards-compatible design as it may otherwise be difficult to fit this in before 1.0 is released.

[arcto]

@alexcrichton, I believe the reason this should be discussed before 1.0 is that, with overloading, some functions in the standard library could possibly be given better/more consistent names.

[arcto]

I agree with @jnicklas in that explicitness makes overloading clearer and simpler - syntactically and semantically, imho. If two functions share parts of the implementation one can always call one function from the other and have the compiler inline the call.

fn foo(a: int, b: int) {...}

fn foo(a: int) {
    ...?
    foo(a, 42);
}

[steveklabnik]

We don't currently have any kind of ordering for declarations, right? This introduces some kind of ordering.

[bstrie]

@arcto, at least in theory, Rust's libraries and tooling have powerful enough support for versioning that it will be possible to evolve the stdlib independent of the language (though each version of the stdlib will obviously require some minimum Rust version), and you'll trivially be able to make use of multiple versions of the stdlib in the same project if you really want.

I agree that it's crucial to have a good stdlib API for 1.0, but this is just pointing out that our definition of "good API" is allowed to change at our leisure over time, as Rust gains features.

[nrc]

Thanks for submitting the RFC. Whilst optional parameters may be something we add to Rust in the future, it is something that has been discussed before and there is broad agreement that it wouldn't be added before 1.0. Therefore, this RFC is extremely likely to be closed as postponed.

[kud1ing]

Therefore, this RFC is extremely likely to be closed as postponed.

Can't it just be left open with a milestone?

[huonw]

We do give them with a "milestone" (i.e. tagged with postponed), but they are closed to try to keep this repo focused and manageable. (NB. discussion of this behaviour is offtopic for this PR: you can open an issue if you see another way we can manage this without leaving a long tail of good-but-postponed RFCs cluttering the UI.)

[brson]

Closing. While optional arguments are an oft-requested feature, it has long been our position that it is non-essential and can be reconsidered backwards-compatibly at some point in the future. Thank you.

[pnkfelix]

This probably should have gotten the postponed label

[pnkfelix]

Filing with RFC issue #323