prefer_explicit_type_arguments

v1.0.0WarningConfigurableType Annotations

This rule flags a call to one of the methods you name, written without explicit type arguments.

This rule is in no preset and reports nothing until you set methods: — for most generic calls inference is right and explicit arguments are noise. The list is the handful of APIs your project has decided are worth pinning.

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

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

Don’t

With showDialog in the list. It infers its type argument from what the builder pops, so a cancel path that pops without a value makes the whole call Future<Null> — and the await yields a null the code did not plan for:

// package:flutter/material.dart, simplified to the signature that matters.
Future<T?> showDialog<T>({required Object builder}) async => null;

Future<void> confirmDelete() async {
  final confirmed = await showDialog(builder: (Object? _) => 'Delete?');
  if (confirmed == true) {
    // Never reached: `confirmed` is statically Null.
  }
}

Do

Pin it. A builder that pops the wrong type is now a compile error, not a silent null at runtime:

// package:flutter/material.dart, simplified to the signature that matters.
Future<T?> showDialog<T>({required Object builder}) async => null;

Future<void> confirmDelete() async {
  final confirmed = await showDialog<bool>(builder: (Object? _) => 'Delete?');
  if (confirmed == true) {
    // Reached when the dialog pops `true`.
  }
}

Adding to a shared list

additional_methods extends whatever methods holds, so a package-level config can add its own names without restating the shared ones:

rules:
  prefer_explicit_type_arguments:
    methods: [showDialog, showModalBottomSheet]
    additional_methods: [pushRoute]

Never reported

A call that resolves to a method with no type parameters is never reported, whatever the name — asking for type arguments there would be asking for a compile error:

// Same name, no type parameters: not reported.
void push(String route) {}

void go() {
  push('/settings');
}

See also: Dart: type inference

Options

analysis_options.yaml
many_lints.yaml

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

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:

rules:
  prefer_explicit_type_arguments: false

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

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()’.