Fn,FnOnce,FnMut with named parameters

1

Hello,

It is impossible to add a name to Fn,FnOnce,FnMut parameters.

For example,

where Builder: FnOnce(id:i32,color:i32,quantity:i32) -> Self

is more expressive than

where Builder: FnOnce(i32,i32,i32) -> Self

Is it a crazy idea to be able to add named parameters when necessary or requested ? Maybe there is a rfc ?

Thank you in advance for your answers.

1 Like
2

There's an RFC issue for this (Naming arguments in Fn traits · Issue #2812 · rust-lang/rfcs · GitHub) and it was also recently supported in parser as an error recovery technique (Parser: Recover error from named params while parse_path by xizheyin · Pull Request #140671 · rust-lang/rust · GitHub).

4 Likes
3

Thank you. The work is on the way then... :+1:

4

Just pass a single struct if you want names.

1 Like
5

I don't think anything has actually happened to that issue (note that it's not even an RFC draft, never mind an accepted RFC). Someone just created an issue (not a PR) that in itself does nothing and doesn't trigger any formal process. [1]

The biggest problem I can see with the idea is that it's not obvious whether the parameter names are pure documentation (as proposed here) or somehow part of the function type. That is, one of the problems with named parameters in general.

  1. I think it should be clarified that issues in the RFC repo should be solely to report specification bugs in accepted RFCs, and RFC proposals and feature requests should be discussed on i.r-l.o instead). ↩︎

6

It's pure documentation, like in function pointers right now.
type Foo = fn(id: i32, color: i32, quantity: i32); is already supported.

1 Like
7

Oh, I didn't know that's permitted. In that case, it would certainly be consistent for the function trait syntax to support it too.

8

I always viewed it as a "consistent with what" matter. You can view dyn Fn(&str) as inconsistent with fn(frobber: &str). But if this feature request lands for types, you could view dyn Fn(frobber: &str) as inconsistent with dyn Fn<(&str,)> / other dyn types / the notional desugaring.[1]

I'm not arguing one way or the other. There are other inconsistencies in the language anyway, such as not being able to elide names in function/method signatures,[2] functions/methods with bodies accepting full patterns but fn(..) and methods without bodies not doing so, etc. All the little differences are collectively a learning speed bump with or without this feature.

  1. Though the OP was about trait bounds, not types; the connection with fn(..) is less direct than that case. ↩︎

  2. mostly ↩︎