Skip to content

tighten-type-of-initializing-formals

Same as tighten_type_of_initializing_formals in Dart lints

Group: Style
Path: lint/style/tighten-type-of-initializing-formals
Default: Off, opt in
Origin: Dart lints
Rule: 442 of 512

Flags a nullable this.x or super.x initializing formal whose constructor asserts x != null.

When a constructor's initializer list asserts that an initializing formal is not null, the parameter should declare a non-nullable type instead, so the check happens at compile time. The assert must be assert(x != null) or assert(null != x) with x naming a this.x or super.x formal of the same constructor whose type is nullable: the explicit parameter type, the field's declared type for an untyped this.x (an untyped field without initializer is dynamic, which counts as nullable), or the super constructor's parameter type for an untyped super.x. A trailing ? or dynamic proves nullability even when the named type itself is unresolved; otherwise unresolved types are never reported. The analyzer treats an undefined type (a compile error) as nullable and reports it, but Falcon cannot tell an undefined type from one declared in a library it does not load. Parenthesized conditions or operands are not the analyzer's direct binary identifier/null test. Repeated asserts on one formal produce one diagnostic.

class A {
  String? p;
  A(this.p) : assert(p != null); // flagged
  A.typed(String this.p);        // ok
}

Invalid

example.dartdart

class A {
  String? p;
  A(this.p) : assert(p != null);
  A.reversed(this.p) : assert(null != p);
  A.typed(String? this.p) : assert(p != null);
  A.named({this.p}) : assert(p != null);
}

class B {
  int? x;
  int? y;
  B(
    this.x,
    this.y,
  ) : assert(x != null),
      assert(y != null);
}

class Base {
  final String? name;
  Base(this.name);
}

class Derived extends Base {
  Derived(super.name) : assert(name != null);
}

class Untyped {
  var value;
  Untyped(this.value) : assert(value != null);
}

class UnresolvedNullable {
  Missing? value;
  UnresolvedNullable(this.value) : assert(value != null);
}

Use a type annotation rather than `assert` to enforce non-nullability.

2 String? p;

3 A(this.p) : assert(p != null);

∙

Use a type annotation rather than `assert` to enforce non-nullability.

3 A(this.p) : assert(p != null);

4 A.reversed(this.p) : assert(null != p);

∙

Use a type annotation rather than `assert` to enforce non-nullability.

4 A.reversed(this.p) : assert(null != p);

5 A.typed(String? this.p) : assert(p != null);

∙

Use a type annotation rather than `assert` to enforce non-nullability.

5 A.typed(String? this.p) : assert(p != null);

6 A.named({this.p}) : assert(p != null);

∙

Use a type annotation rather than `assert` to enforce non-nullability.

12 B(

13 this.x,

∙

Use a type annotation rather than `assert` to enforce non-nullability.

13 this.x,

14 this.y,

∙

Use a type annotation rather than `assert` to enforce non-nullability.

24class Derived extends Base {

25 Derived(super.name) : assert(name != null);

∙

Use a type annotation rather than `assert` to enforce non-nullability.

29 var value;

30 Untyped(this.value) : assert(value != null);

∙

Use a type annotation rather than `assert` to enforce non-nullability.

34 Missing? value;

35 UnresolvedNullable(this.value) : assert(value != null);

∙

Valid

example.dartdart

class A {
  String? p;
  A.typed(String this.p);
  A.other(this.p);
  A.unrelated(this.p, String? q) : assert(q != null);
  A.nonNull(String this.p) : assert(p != null);
  A.otherCheck(this.p) : assert(p == null);
}

class B {
  final int x;
  B(this.x) : assert(x != null);
}

class C {
  final String? s;
  C(String? value) : s = value, assert(value != null);
}

class Base {
  final String name;
  Base(this.name);
}

class Derived extends Base {
  Derived(super.name) : assert(name != null);
}

class Inferred {
  var value = 0;
  Inferred(this.value) : assert(value != null);
}

Configure tighten-type-of-initializing-formals

Set its severity in falcon.json. See the configuration guide.

falcon.jsonjson

{
  "linter": {
    "rules": {
      "style": {
        "tighten-type-of-initializing-formals": "error"
      }
    }
  }
}

Or silence one occurrence with a suppression comment; the reason is required.

example.dartdart

// falcon-ignore lint/style/tighten-type-of-initializing-formals: <reason>

type-annotate-public-apistype_annotate_public_apisrecommended
Requires type annotations on public declarations.
type-init-formalstype_init_formalsrecommended
Flags a *redundant* type annotation on an initializing formal or super parameter (type-init-formals, adopted from package:lints).
unawaited-futuresunawaited_futuresrecommended
Future results in async bodies must be awaited or marked unawaited.
unintended-html-in-doc-commentunintended_html_in_doc_commentrecommended
Flags angle-bracket text in doc comments that Markdown would render as an HTML tag.
unnecessary-await-in-returnunnecessary_await_in_return
Avoid await on a returned Future the function's own Future already covers.
unnecessary-brace-in-string-interpsunnecessary_brace_in_string_interpsrecommended
Flags ${x} string interpolations whose braces can be dropped.
unnecessary-breaksunnecessary_breaksrecommended
Flags a trailing break in a switch case that already ends implicitly.
unnecessary-constructor-nameunnecessary_constructor_namerecommended
Flags a redundant .new on constructor declarations and invocations.