Hm, I'm wondering if this was stabilized accidentally. This was added in rust-lang/rust#57760 (RFC 2137), see also rust-lang/rust#44930 and rust-lang/wg-grammar#45.

Is there any meaning to the identifier of a variadic parameter? Or is it just ignored? That should probably be documented.

(Or, if this was truely a mistake, maybe it should be reverted/fixed/made unstable?)

I don't know, I guess cc @Centril / @petrochenkov ?

But apparently people use this in the real world already, this was reported against rust-analyzer.

The function parameter grammar as implemented in rustc is as follows. I've invented new meta grammar notation here, but it should hopefully be understandable.

Let RN ("require name") be a function Edition -> Bool. Then the (higher order) grammar is:

FnParams<RN> = "(" head: FirstParam<RN> tail: { "," Param<RN> %% "," } ")" ;

FirstParam<RN> = SelfParam | Param<RN> ;
Param<RN> = CVariadicTy | AlwaysNamedParam | MaybeNamedParam<RN> ;

MaybeNamedParam<RN> if RN(edition(current_token)) = Pat ":" ParamTy ; // Named param.
MaybeNamedParam<RN> = ParamTy ; // Unnamed param.

// Ambiguous with ^-- but for precedence.
AlwaysNamedParam = NamedStart? Ident ":" ParamTy ;
NamedStart = NtPat | "&" | "&&" | "mut" ;

ParamTy = CVariadicTy | TyPlusAllowed ;
CVariadicTy = "..." ;

For:

• function pointers, let RN = \_ -> False,
• functions in traits, let RN = \edition -> edition > 2015,
• otherwise, let RN = \_ -> True.

This is translated starting with parse_fn_params in the rustc parser.

Beyond this, AST validation imposes other semantic restrictions.