[lint] Specify the type of a local variable when the type is non-obvious on private types get bad result

[stephane-archer]

      child: IconButton(
        icon: Icon(
          Icons.delete_outline,
          color: isProcessing
              ? Colors.grey.withValues(alpha: 0.3)
              : Colors.redAccent,
        ),
        onPressed: isProcessing
            ? null
            : () async {
                final favoriteFoldersNotifier =
                    ref.read(favoriteFoldersProvider.notifier);
                await favoriteFoldersNotifier.removeFavoriteFolders(folder);
              },
      ),

Specify the type of a local variable when the type is non-obvious. Try adding a type annotation.

apply quick fix:

      child: IconButton(
        icon: Icon(
          Icons.delete_outline,
          color: isProcessing
              ? Colors.grey.withValues(alpha: 0.3)
              : Colors.redAccent,
        ),
        onPressed: isProcessing
            ? null
            : () async {
                final AsyncNotifier<List<Directory>> favoriteFoldersNotifier =
                    ref.read(favoriteFoldersProvider.notifier);
                await favoriteFoldersNotifier.removeFavoriteFolders(folder);
              },
      ),

The method 'removeFavoriteFolders' isn't defined for the type 'AsyncNotifier'. Try correcting the name to the name of an existing method, or defining a method named 'removeFavoriteFolders'.

Here the type should be _FavoriteFoldersAsyncNotifierInterface. I think the lint gets confused because the type is private (it shouldn't)

[FMorschel]

The lint will always suggest that when the type is not obvious.

Is the type available at the library you used the quick-fix? Or is it declared somewhere else?

If it is declared somewhere else, this is exactly all the fix can do. Add the closest public type it found.

[stephane-archer]

That type is declared in another file but it's the same lib directory

Just it start with an _ because I thought it was not use outside the file, but it's not true, just the type was not visible because of the use of the var without the type specified (the lint could rename the type)

[FMorschel]

Rename is a refactor. It changes more things than a "quick-fix" can do. We currently have no way of suggesting refactors as a fix for a diagnostic.

But still, that is not necessarily what you would want to do here (generally speaking, renaming things is breaking), and we don't analyze what members are being accessed (to know where they are declared) in order to provide the quick-fix here.

CC @srawlins @bwilkerson

[stephane-archer]

I don't know what I would consider best.
The linter can:

• not trigger because the type it should suggest is private
• or it can put the private type and it's up to the user to make this type available ?

Currently the type that has been suggested by the quick fix has nothing to do with the underlying type and the code produced is invalid so I think the other options are simply better in that case.

What is your thoughts on this ?

[FMorschel]

not trigger because the type it should suggest is private

I disagree. The linter has no idea if the declarations of the type you'll need are part of the private type only, or if you are actually accessing public members from a public supertype. And doing that analysis is really time-consuming and not worth it for the lint. The private type could simply be an internal implementation of a completely public interface, so you could be safe by adding that type there.

or it can put the private type, and it's up to the user to make this type available ?

Our quick-fixes have the goal of not generating more diagnostics (new error codes) if possible to avoid. So we could either go back to the previous behaviour of not adding any type at all (this changed when this landed) because the type is private (which is confusing on its own way), or we can keep the current behaviour, which will be valid for most cases.

has nothing to do with the underlying type

Are you definitely sure of that? It should be a super type of the private type you are trying to use:

// consider this a.dart
class A {
  void foo() {}
}

// consider this b.dart
import 'a.dart';

class _B extends A {
  void bar() {}
}

_B fn() => _B();

// consider this main.dart
import 'b.dart';

void main() {
  var myBValue = fn();
}

The quick-fix on main.dart should produce A.

The actual problem comes from the fact that you are going against library_private_types_in_public_api (see the docs), which would tell you to use A (or Object or a similar supertype) at _fn instead of _B.

[stephane-archer]

myBValue.bar() would work perfectly before the lint is applied right?

So the lint produces invalid code here.

I agree that this code does not respect library_private_types_in_public_api

But in this particular case, the lint didn't trigger (see this issue)

Regardless, this is valid Dart code, even if a lint exists to prevent this situation, and the lint should do something about the fact that it produces invalid code

[FMorschel]

I will open an issue for this too

Thanks!

---

WDYT @bwilkerson @srawlins

[srawlins]

[The lint rule / quick fix] it can put the private type and it's up to the user to make this type available ?

This would be my preference. That the lint rule not change. Whether the quick fix adds the private type, or is just not available, I don't have a strong preference.

[FMorschel]

I agree. I think the best solution here would be to fix #62669 since it is the source of the problem.

I don't think there is anything we can do around specify_nonobvious_local_variable_types or Add type annotation to make this situation better, unfortunately.

[stephane-archer]

@FMorschel, regarding this issue, we can not assume specify_nonobvious_local_variable_types is used with library_private_types_in_public_api by the user. So I don't think a patch to library_private_types_in_public_api is the solution here.

Whether the quick fix adds the private type, or is just not available, I don't have a strong preference either, but I believe both would result in a better dev experience compared to what we currently have (a vaguely similar type)