In Dart, how does var infer a local variable's type, and what happens when a var declaration has no initializer?

## var means "infer", not "anything" Dart is statically typed with **type inference**. Writing `var` asks the analyzer to work out the variable's static type from its initializer, exactly as if you had written it: ```dart var miles = 3; // int var name = 'mile'; // String var factors = {'mi': 1609.344, 'ft': 0.3048}; // Map<String, double> ``` After that the variable has a fixed static type. It is not a JavaScript-style variable that can hold any kind of value: in JavaScript, `var` only declares a name, while in Dart it declares a name *and* fixes its type from the initializer. ## Inference happens once dart.dev's type-system page states the rule for locals: types are inferred from the initializer, if any, and **subsequent assignments are not taken into account**. That can infer a narrower type than you meant: ```dart var distance = 3; // int distance = 4.0; // error: a double can't be assigned to an int ``` The fix is an annotation with the type you actually want: ```dart num distance = 3; distance = 4.0; // fine ``` `final` and `const` infer the same way: `final loadedAt = DateTime.now();` is a `DateTime`. ## No initializer, no inference If the declaration has no initializer, there is nothing to infer from. Effective Dart explains that when inference lacks information, Dart usually **fills in `dynamic` silently**, and that implicit `dynamic` looks safe but disables type checking. So: ```dart var unit; // static type: dynamic unit = 'km'; unit = 42; // accepted unit.toUpperCase(); // compiles; throws NoSuchMethodError at runtime ``` That is why Effective Dart has the rule **"DO type annotate variables without initializers"**, backed by the `prefer_typing_uninitialized_variables` lint, which sits in the core, recommended and flutter lint sets. With an annotation, flow analysis still lets you assign later, as long as every path assigns before use: ```dart double factor; if (unit == 'mi') { factor = 1609.344; } else { factor = 1.0; } ``` ## Where inference applies | Declaration | Type comes from | |---|---| | Local `var`/`final` with initializer | The initializer | | Local `var` without initializer | Nothing: `dynamic` | | Top-level or static variable | Its initializer | | Instance field overriding a superclass member | The inherited type | | Instance field with an initializer | The initializer | Top-level inference has one more failure mode: it fails if the type depends on itself through a cycle. ## Common mistakes 1. Declaring `var result;` and assigning values of several types: the variable is silently `dynamic`, and errors move from the analyzer to runtime. 2. Writing `var distance = 3;` and later needing fractions: write `double distance = 3;` or `var distance = 3.0;` instead. 3. Writing `dynamic` explicitly where `var` would infer a precise type: it throws away checking for no benefit. 4. Believing `var` is weaker than an explicit type: once inferred, the type is enforced exactly as if it had been written. The unifying idea is that inference is a convenience for **writing** types, never a switch to dynamic typing, except in the one case where there is nothing to infer from. ## Style: when to write the type Effective Dart's summary is short: - **Don't** annotate initialized local variables; `var` or `final` is enough. - **Do** annotate when inference lacks context, including uninitialized variables. - **Prefer** annotating top-level variables and fields unless the initializer makes the type obvious. In a unit-conversion library that means `final factor = metersPerMile / metersPerFoot;` inside a function, but explicit types on public top-level values, where the annotation documents the API. Note that `const double metersPerKilometer = 1000;` is fine: an integer literal in a `double` context becomes a `double`.