{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiawszyeytev2earmtafydhwvxc6g67gnt324rdzbhdej4e73t62bm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfqdxlbk5ph2"
  },
  "path": "/t/pre-rfc-function-parameter-defaults/24011#post_12",
  "publishedAt": "2026-02-26T03:30:09.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "↩︎"
  ],
  "textContent": "Hmm... I just thought of a problem with defaults in trait methods. The default value can be exclusive to the trait definition site:\n\n\n    trait Trait {\n        fn it(a: &str = include_str!(\"the_golden_gate_bridge.txt\"));\n    }\n\n\nAs far as I know, `the_golden_gate_bridge.txt` needs to be present at build time because dependency crates are usually built from source. But the exact path it's in is non-trivial to figure out.\n\nIts value may be expanded and statically displayed on docs.rs, but that's also a problem if the file is 1GB.[1]\n\n* * *\n\n\n    // In crate aaa\n    trait Trait {\n        fn it(a: &bool = cfg!(feature = \"feature\"));\n    }\n\n\nThis extracts the `feature` config of crate `aaa`, and cannot be copy-and-pasted to user crate `bbb` because it would refer to the `feature` config of `bbb` instead. Instead `bbb` will need to sync the default value with its Cargo.toml (or something else?).\n\n* * *\n\nGiven the above, it seems like a good idea to delay default values in trait methods to another RFC?\n\n* * *\n\n  1. Has anyone ever needed to embed 1GB of data into their code like that? I'd be interested to hear your use case\n\nI just thought of this being a possible DoS vulnerability to docs.rs, but that seems false as the size of default values in generated HTML is equal to their size in the compiler's RAM (or AST representation at least?), so sandboxing the compiler is sufficient (not sufficient if the compiler optimizes to eliminate memory duplication of constants)\n\n↩︎\n\n\n",
  "title": "Pre-RFC: Function parameter defaults"
}