[linter] avoid_dynamic_construtor_arguments

[stephane-archer]

Is there any lint to avoid dynamic constructor arguments?

class FavoriteFoldersCardWidget extends StatelessWidget {
  final TextStyle _h1;

  const FavoriteFoldersCardWidget({
    super.key,
    required h1, // this is dynamic by mistake
  }) : _h1 = h1;

  @override
  Widget build(BuildContext context) {
    return Card(
      surfaceTintColor: Colors.blue,
      child: Padding(
        padding: const EdgeInsets.all(15.0),
        child: Text("hello word", style: _h1),
      ),
    );
  }
}

[bwilkerson]

I believe that always_specify_types will cover this case, but it might do more than you want.

@eernstg Formal parameters don't appear to be covered by any of the specify_nonobvious_X_types lints that were recently added. Should we consider adding a lint that won't conflict with the specify_nonobvious_X_types lints that cover places where the type can't be inferred?

[stephane-archer]

@bwilkerson I want to be able to use var in my code. always_specify_types is too much annoying.

I want to avoid dynamic in my code and not always specify the type.

[bwilkerson]

I want to be able to use var in my code. always_specify_types is too much annoying.

Yep. I expected as much.

I want to avoid dynamic in my code and not always specify the type.

That's the motivation behind the experimental specify_nonobvious_local_variable_types and specify_nonobvious_property_types lints. They will only point out places where the use of var results in the type being implicitly dynamic. But, to the best of my knowledge, neither of those will flag parameter declarations.

[stephane-archer]

@bwilkerson that would be a nice addition if we could add a new linter or update an existing one

[lrhn]

This feels like something that should be included in one of the strict-"mode" lints.
Not specifying a parameter type and getting dynamic is ... found it: It's exactly what strict-inference should warn about.

[stephane-archer]

@lrhn strict-inference does not include it right now right?

the name is technically correct but I don't expect someone with issues regarding dynamic to find it.
the name reflects the solution rather than the problem the user has.

[lrhn]

strict-inference should warn here. If it doesn't, that's probably a bug.

This is a parameter without a declared type, which is used inside the declaration.

It's not used inside the body, but it's used by the initializer list, so it's not unreferenced.

The "strict" lints are generally pointed to add the way to avoid implicit dynamic. I worry more that they're not enabled the same way as other lints than about their names.

[stephane-archer]

@lrhn strict-inference warn here. I had to restart vscode, I think my analyzer was in a bad state when I first tested.
strict-inference should be added in https://dart.dev/tools/linter-rules otherwise nobody will ever find it

I just found quite a few issues relating empty list ([]) and constructor parameters, that's quite a useful lint

[eernstg]

I think the core of this issue has been resolved: Setting strict-inference to true in analysis_options.yaml addresses the request in the OP. This is the right way to go for anything that involves unexpected (and invisible) occurrences of the type dynamic.

However, another thing came up:

@bwilkerson wrote:

Formal parameters don't appear to be covered by any of the specify_nonobvious_X_types lints that were recently added. Should we consider adding a lint that won't conflict with the specify_nonobvious_X_types lints that cover places where the type can't be inferred?

That's an interesting connection! specify_nonobvious_local_variable_types and specify_nonobvious_property_types rely on an initializing expression which is right there in the declaration which is being checked.

double foo() => 10.5;

var x = foo() + 1; // Linted by `specify_nonobvious_property_types`.

void main() {
  var y = foo() + 1; // Linted by `specify_nonobvious_local_variable_types`.
}

In both cases, the lint checks that foo() + 1 has a static type which is not evident from the kind of expression itself (foo() could have any return type, and so could the operator + of that return type). Hence, it should have an explicit type annotation when we've chosen to enable this lint (that would be double x = foo() + 1;).

We don't immediately have anything of the same nature when it comes to formal parameter declarations, even in the situation where the function is a function literal. In particular, a formal parameter of a function literal can have its type inferred from part of the context type, but even in that case there's no expression. Instead, we're directly using a type annotation, which means that the whole problem targeted by the specify_nonobvious... lints (namely: looking at an expression and determining its static type) has already been solved.

We do have something of a somewhat similar nature, though:

void foo(void Function(int) g) {}

void main() {
  void Function(int) f = (i) {}; // Inferred as `(int i) {}`.
  foo((i) {}); // Inferred as `(int i) {}`.
}

In this case we aren't interested in the distinction between obvious and non-obvious types. A more useful distinction is that the parameter type in the declaration of f is visible in the syntactic context of the function literal, but it is implicit in the invocation of foo.

We might be able to create a lint that asks for an explicit parameter type annotation in the case where the given type isn't visible locally. I'm sure there will be some murky corners in that idea, but it does seem to be a viable policy that some developers or organizations might want to adopt.

On the other hand, I suspect that the case where the parameter type isn't visible locally will be vastly more common than the case where the type is visible locally. This probably means that it isn't useful enough to have this "declare the parameter type if not locally visible" lint.

Also, 'Effective Dart' plainly recommends omitting the type annotations on function literal parameters, with no exceptions. This rule hasn't given rise to much controversy, so the Dart community seems to be happy with this rule.