prefer_explicit_type_arguments

v1.0.0WarningConfigurableType Annotations

This rule flags a configured generic call written without explicit type arguments.

This rule is in no preset, and reports nothing until configured — for most generic calls inference is right and explicit arguments are noise.

Why use this rule

Inference is usually correct and usually invisible, which is exactly the problem for a handful of APIs.

showDialog(...) infers its return type from the builder’s Navigator.pop(value). A pop() with no argument silently makes it Future<Null>, and the await at the call site yields a null the code did not plan for — at runtime, far from the pop() that caused it. Writing showDialog<bool>(...) moves that decision into the signature, where a mismatch is a compile error.

The rule is a list of the APIs your project has decided are worth pinning:

rules:
  prefer_explicit_type_arguments:
    methods: [showDialog, showModalBottomSheet, push, pushNamed]

A call that resolves to no type parameters is never reported — asking for type arguments there would be asking for a compile error.

See also: Dart: type inference

Don’t

// Infers Future<Null> if the builder pops without a value.
final result = await showDialog((_) => const MyDialog());

Do

final result = await showDialog<bool>((_) => const MyDialog());

Options

analysis_options.yaml

analysis_options.yaml

many_lints:
  rules:
    prefer_explicit_type_arguments:
      methods: [showDialog, showModalBottomSheet]

many_lints.yaml

many_lints.yaml

rules:
  prefer_explicit_type_arguments:
    methods: [showDialog, showModalBottomSheet]

Option	Type	Default	Description
methods	list of strings	[]	Method names that must carry explicit type arguments. Empty means the rule is silent
additional_methods	list of strings	[]	Names to add to that list

Turning this rule off

To disable this rule:

many_lints.yaml

rules:
  prefer_explicit_type_arguments: false

To keep the rule on but skip certain paths, use per-rule exclude.

Related rules

• prefer_explicit_function_type — Prefer explicit function type annotations over the bare ‘Function’ type.
• prefer_explicit_parameter_names — Name the parameters of a function type.
• prefer_type_over_var — Prefer an explicit type annotation over ‘var’.
• prefer_async_callback — Use ‘AsyncCallback’ instead of ‘Future<void> Function()’.