Don't require type annotating unused parameters

[Lootwig]

is there a hack/feature/workaround to not have to manually ignore each of these?

[felangel]

Hi @Lootwig 👋
Thanks for opening an issue!

Can you give some more context regarding the code in those files? Is it generated via build_runner? Are you able to share snippets of the relevant code?

Thanks!

[Lootwig]

Here you go - the following file will cause the _ parameter to be highlighted, except if setting implicit-casts and implicit-dynamic in the strong-mode section of analysis_options to true:

import 'package:flutter/widgets.dart';

class A extends StatelessWidget {
  const A({Key? key}) : super(key: key);

  @override
  Widget build(_) { // I don't need the context :(
    return Container();
  }
}

[Lootwig]

@felangel not sure if overriding my reply serves the readability of the thread :) (plus, there's no notification, luckily I still had the page open to see the update)

anyway - I'm not sure if I agree that the "public method" aspect by itself justifies the need to specify it, would you care to elaborate? i.e., from my POV as "the overrider", the parameter is just dead weight anyway that (in this case) I wish I wouldn't have to list in the first place, but am required to, so adding more verbosity seems like.. idk, rubbing it in, maybe? :D

[felangel]

Ah oops I meant to reply! Sorry I reverted 😅

In that case, it's recommended to still specify the type even if you don't need the context since this is a public method that is being overridden:

import 'package:flutter/widgets.dart';

class A extends StatelessWidget {
  const A({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext _) {
    return Container();
  }
}

[felangel]

@felangel not sure if overriding my reply serves the readability of the thread :) (plus, there's no notification, luckily I still had the page open to see the update)

anyway - I'm not sure if I agree that the "public method" aspect by itself justifies the need to specify it, would you care to elaborate? i.e., from my POV as "the overrider", the parameter is just dead weight anyway that (in this case) I wish I wouldn't have to list in the first place, but am required to, so adding more verbosity seems like.. idk, rubbing it in, maybe? :D

Actually I took a closer look and it seems like the warning you're referring to is:

The parameter '_' should have the name 'context' to match the name used in the overridden method.
Try renaming the parameter.

You shouldn't rename parameters for overridden methods.

For this particular case, you should maintain the existing parameter name and type since it's an overridden public api:

@override
Widget build(BuildContext context) {
  // ...
}

[Lootwig]

My bad! I had a simpler example first, but then wanted to try find a more relatable example and failed.
The link is indeed helpful for the overriding case! A few instances of these errors concern implementations like this:

final iterableMap = Map<int, String>.fromIterable(
  <int>[0, 1, 2],
  value: (_) => 'A', // is this considered an override, too?
);

[felangel]

My bad! I had a simpler example first, but then wanted to try find a more relatable example and failed. The link is indeed helpful for the overriding case! A few instances of these errors concern implementations like this:

final iterableMap = Map<int, String>.fromIterable(
  <int>[0, 1, 2],
  value: (_) => 'A', // is this considered an override, too?
);

No problem! In that case, it's an implicit dynamic issue so to resolve you'd need to explicitly specify the dynamic type:

final list = Map<int, String>.fromIterable(
  <int>[0, 1, 2],
  value: (dynamic _) => 'A', // is this considered an override, too?
);

[Lootwig]

I guess that's the "excessive verbosity" part I was referring to above.

Off-topic, I guess: Do you know of any way to at least have intellisense include a typedef's types when generating the function stub? E.g. in the above case, pressing (IntelliJ) Ctrl+Space, the code is just (element) => , so you have to manually update these to make the linter happy.

[felangel]

I guess that's the "excessive verbosity" part I was referring to above.

Off-topic, I guess: Do you know of any way to at least have intellisense include a typedef's types when generating the function stub? E.g. in the above case, pressing (IntelliJ) Ctrl+Space, the code is just (element) => , so you have to manually update these to make the linter happy.

I think that's just a limitation of the plugin/extension unfortunately :(