{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicgphnah3fdi2a3n6carkzojzui4wm7lk2j764inizjn2tgy5lxzu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfoghswrpwc2"
  },
  "path": "/t/pre-rfc-function-parameter-defaults/24011#post_3",
  "publishedAt": "2026-02-25T06:46:16.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "It's a breaking change to add `Fn*` impls (they are fundamental traits), but there are probably ways around that.\n\n  * Accept it anyway due to negligible breakage as function items aren't nameable\n  * Consider each arity to be a different type\n\n\n\n* * *\n\n\n    fn f(_: bool, _: i32 /* = 0 */) {\n    }\n\n    fn g(_: bool, _: i32 /* = 1 */) {\n    }\n\n    fn ex() {\n        let _array = [f, g];\n    }\n\n\nThis compiles today, and you have `[fn(bool, i32); 2]`. Conceivably if both have defaults, it could be `[fn(bool); 2]` instead. So it's at least in some senses ambiguous. Alternatively, there could be some fallback preference for \"no defaults\"...\n\n...but then consider if `f` adds a third defaulted arg `_: f64`, and at some later point, `g` does too. Now it infers to a new type, either changing semantics or breaking code. (If the fallback is \"all defaults\" you have the opposite problem.)",
  "title": "Pre-RFC: Function parameter defaults"
}