Functions & Parameters

## Three kinds of parameters A Dart function declares its parameters in up to two groups: 1. **Required positional parameters** come first, in order: `String formatPrice(num amount)`. Every call must pass them, by position. 2. Then **either** a group of **optional positional** parameters in square brackets, `[String currency = 'EUR']`, **or** a group of **named** parameters in braces, `{int decimals = 2, bool showSign = false}`. A single function cannot have both groups. | | Declared as | Passed as | Optional? | |---|---|---|---| | Required positional | `f(int a)` | `f(1)` | no | | Optional positional | `f([int a = 0])` | `f()` or `f(1)` | yes | | Named | `f({int a = 0})` | `f()` or `f(a: 1)` | yes, unless marked `required` | ## Defaults and nullability An optional parameter, positional or named, needs a way to have a value when the caller leaves it out: - give it a **default value** with `=`; the default must be a **compile-time constant**; - or make its type **nullable**, in which case the implicit default is `null`: `[String? device]`, `{bool? bold}`; - a named parameter can instead be marked **`required`**, so the analyzer rejects calls that omit it. The rules around `required` are part of null safety and covered there. A non-nullable optional parameter with no default is a compile error, because `null` would be its only possible default. ## Why named parameters dominate Dart APIs Named arguments make call sites readable, especially for booleans and numbers whose meaning is not obvious from the value: ```dart formatPrice(1299.5, decimals: 0, showSign: true); // versus a positional mystery: formatPriceOld(1299.5, 'EUR', 0, true); ``` They also let callers skip any subset of options, which optional positional parameters cannot do without passing every earlier one. That is why Flutter widget constructors use named parameters almost exclusively, even for mandatory ones such as a `child`, marked `required`. Since Dart 2.17, **named arguments can appear anywhere in the argument list**, not only after the positional ones. That is what makes `repeat(times: 2, () { ... })` legal, with a trailing callback after a named argument. ## When optional positional still fits Optional positional parameters suit a short, natural progression where earlier arguments are passed more often than later ones. The SDK's own examples are `String.fromCharCodes(charCodes, [start = 0, end])` and the `DateTime(year, [month = 1, day = 1, ...])` constructor. If a caller might want to pass a later one while omitting an earlier one, switch to named. ## Parameter modifiers in Dart 3.13 Since Dart 3.13, `final` and `var` on an ordinary function, method, closure or in-body constructor parameter are a **compile-time error** (`extraneous_modifier`); those modifiers are reserved for primary constructors, where they declare fields. To keep parameters from being reassigned as a style rule, enable the `parameter_assignments` lint. ## Common mistakes - **Mixing both optional groups**: `f(int a, [int b = 0], {int c = 0})` is rejected; pick one. - **A non-constant default**: `{DateTime at = DateTime.now()}` does not compile. Use a nullable parameter and resolve it in the body. - **Booleans passed by position**: `formatPrice(9.99, 'EUR', 0, true)` compiles, but nobody can read it in review, and swapping two same-typed arguments goes unnoticed. - **Treating named as required**: a named parameter without `required` is optional, so a caller can silently omit it and get the default. - **Explicit `= null` defaults**: a nullable optional parameter already defaults to `null`; the `avoid_init_to_null` lint, in the `recommended` and `flutter` sets, flags the redundant form. ## What an interviewer listens for - The three kinds and the "positional first, then `[]` or `{}` but not both" rule. - Constant defaults and the nullable alternative. - A reason for choosing named parameters: readability and skipping. - Awareness that Flutter APIs are built on named parameters.