In Ruby, what does `def send_email(to:, subject: "(no subject)", cc: [])` declare, and what happens when a caller omits `to:` or adds `bcc:`?

## What the signature declares A **keyword parameter** is a method parameter that the caller fills by name rather than by position. In a `def`, it is written as a name followed by a colon. What comes after the colon decides whether the caller must supply it: | Form in the `def` | Kind | If the caller omits it | |---|---|---| | `to:` | required keyword | `ArgumentError`: `missing keyword: :to` | | `subject: "(no subject)"` | optional keyword | the default string is used | | `cc: []` | optional keyword | a new empty Array is used | So `def send_email(to:, subject: "(no subject)", cc: [])` accepts exactly three names. Nothing else is allowed unless the method also declares a keyword splat (`**opts`), which gathers extra names into a Hash. ## How callers pass keywords - Keywords are written as `name: value` pairs in the call: `send_email(to: "[email protected]", subject: "Invoice")`. - **Order does not matter.** `send_email(subject: "Invoice", to: "[email protected]")` binds the same values. - Keywords come **after** any positional arguments. A method can mix both: `def send_email(template, to:, cc: [])` is called as `send_email(:welcome, to: "[email protected]")`. - The names are **Symbols** matched exactly. `To:` or `"to"` is a different name and does not fill `to:`. - A keyword's value can be any expression, such as `send_email(to: user.email, cc: team.map(&:email))`; it is evaluated by the caller before the call, like any other argument. ## When the defaults are evaluated Ruby binds arguments in a fixed sequence each time the method is called: 1. It matches every keyword the caller passed against the declared names. 2. For each optional keyword the caller left out, it **evaluates the default expression now**, left to right. 3. Only then does the method body start. Two consequences follow. First, `cc: []` builds a **new Array on every call** that omits `cc:`, so appending to `cc` inside the method never leaks into the next call. Second, a default may refer to parameters declared **to its left**, which is handy for derived settings: ```ruby def send_email(to:, reply_to: to, subject: "(no subject)") [to, reply_to, subject] end send_email(to: "[email protected]") # => ["[email protected]", "[email protected]", "(no subject)"] ``` A default can also call a method on `self`, such as `from: default_sender`, because it runs inside the method's own context. ## The two errors and their exact messages Both failures are `ArgumentError`, raised while the arguments are bound, so the body never runs with a half-filled signature. - **Missing required keyword.** `send_email(subject: "Hi")` raises `missing keyword: :to`. With several absent, Ruby lists them all in one plural message: `missing keywords: :to, :from`. - **Unknown keyword.** `send_email(to: "[email protected]", bcc: "[email protected]")` raises `unknown keyword: :bcc`. Several unknown names are reported together, `unknown keywords: :bcc, :priority`. - The names appear in their `inspect` form, which is why each keeps its leading colon. Because the check happens during binding, the error is raised at the caller's line, where the fix belongs, and not somewhere deep in the delivery code. This strictness is a feature. A typo such as `subjcet:` fails loudly at the call site instead of being silently dropped, and a forgotten recipient cannot reach the delivery code as `nil`. ## What does not happen Several beliefs carried over from other code styles are wrong for Ruby keywords: - An omitted required keyword is **not** set to `nil`; the call fails. - An unknown keyword is **not** ignored; without `**opts` it is an error. - A missing keyword is **not** a `KeyError`. That class belongs to lookups such as `Hash#fetch`, not to argument binding. - The default `[]` is **not** shared between calls, because the expression is re-evaluated on each call that needs it. ## Why interviewers ask it The question checks whether a candidate reads a signature precisely: which parameters are mandatory, which have fallbacks, and what the method will reject. For an email-sending API, required keywords make the essentials (`to:`) impossible to forget, optional keywords document every setting with its default in one line, and strict name checking catches misspelled options the moment a caller writes them. The next step up, collecting extra settings with `**opts` or refusing keywords with `**nil`, trades part of that strictness for flexibility.