strict_top_level_inference is triggered for wildcard variables

[ngoc-quoc-huynh]

The new strict_top_level_inference rule triggers a lint warning when using a wildcard (_) as a function parameter. I'm not sure if this is intentional, but I would expect the wildcard to be exempt since its type is irrelevant and cannot be used.

void foo() {
    const ValueChanged<int> onChange = _onChange;
}

// Lint warning 
void _onChange(_) => print('I do not need the value.');

[bwilkerson]

@kallentu @pq

[lrhn]

I've hit this too. It's surprising, but I'm not sure it's wrong. Also not sure it isn't.

The lint says that a top-level declaration should have types. The _ variable says that the parameter value won't be used, and it has no name, but that doesn't mean it has no type. It'll default to dynamic, which is exactly what this lint tries to avoid. But it'll be for a variable that nobody references, so there won't be a dynamic expression anywhere because of that, so there is no damage.

There could be an exception to the lint for _ parameters, as an "I don't care". At least if it's not a public instance member.
Such functions are mostly used in testing anyway, that's where I hit it, and it didn't feel like an improvement to have to write Object?.

(So, probably a good idea to exempt _, because there is no real benefit for enforcing a type of something that nobody will everr refer to.)

[bwilkerson]

The lint says that a top-level declaration should have types.

Yep. But the doc, which were written before wildcard variables existed, doesn't answer the question of why, which is what's really needed in order to answer the question of whether the current behavior is correct. That's a failure on the part of the docs.

... so there won't be a dynamic expression anywhere ...

And I believe that that's the 'why' for this lint. And if that's what the lint is trying to accomplish, then wildcard variables should be exempt because, as you noted, you can't reference the variable and hence can't introduce dynamic into an expression.

[srawlins]

When the wildcard-variables language feature was enabled in the flutter SDK repo, we saw a few cases like this. The few cases were where a method is declared, but never directly called. Instead, the method exists to be a callback in some external API. The callback has to have a signature where it accepts a parameter, but the parameter isn't used, so the name of the parameter is _, and no type is given.

This leads me to the question: are there performance implications? Like in the following code:

class C {
  void whereCb(_) => true;
  void f(List<int> p) {
    p.where(whereCb);
  }
}

The whereCb method's signature is void Function(dynamic). And p.where expects a void Function(List<int>), so a cast takes place... I think. Are there performance implications to that cast?

I dunno, even if not. This code involves declaring a function with signature void Function(dynamic), because the parameter isn't used. I'm not excited already. Then it's passed as a callback to a parameter with a different signature. ☹

[lrhn]

so a cast takes place

No cast needed, a void Function(dynamic) is a subtype of void Function(T) for any type T.

If the parameter the function is passed to is covariant (usually by generics), then there is a type check on entry. That type check should be faster if the parameter type of the argument function is a top type, because that trivially satisfies any parameter type.

The whereCb should be private and static. (But neither exempts it from this lint.)

[FMorschel]

Not related to the meaning but because of the same feature (wildcard variables):

• Evaluation results in different variable #60121

[kallentu]

Working on a fix to this at the moment.