{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibeabxzxfxgbhmfcrr2242ulqgahyc5d4cqu72cqed3w3cf3g67oy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfp5vvrps3r2"
  },
  "path": "/t/pre-rfc-function-parameter-defaults/24011#post_8",
  "publishedAt": "2026-02-25T16:39:33.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "jplatte:\n\n> Well, this thread is about function parameter defaults, not named parameters. I posted it independently (a) because an RFC with both would be way too big IMO, and (b) because I think this makes sense as a feature on its own.\n\nI don't think they're considerable in isolation, really. (And they're both mentioned in the OP.)\n\nFunction parameter defaults, at least assuming that more than one is allowed, to me inherently want named parameters to avoid the `foo(1, None, None, None, None, None, 30)` problem and be able to write `foo(1, blah = 30)` (or whatever) instead.\n\n(Or, alternatively, they end up wanting overloading to be able to make different sets of possible arguments, but that has different -- worse IMHO -- problems.)\n\njplatte:\n\n> The text above has a Motivation section, so I don't understand this criticism.\n\nSpecifically to me the Rationale & Alternatives section is the most important, because it's about _why_ things work this way and why it's better than other possibilities.\n\nThe extant motivation section is basically just \"I want function parameter defaults\". It could similarly be the motivation section for \"I want overloaded functions\" -- where they're both just named `new` instead of having a default for the second parameter -- with almost zero changes.",
  "title": "Pre-RFC: Function parameter defaults"
}