False positive for `unused_field`/`unused_element` warning

[lrhn]

Example code:

typedef Public = _Private;

class _Private {
  static const int constValue = 42;
  static int value = 42;
  static int method() => 42;
  _Private();
  _Private.name();
}

The analyzer gives "unused" warnings for the const, variable and method, but not for the constructors.

If I remove the typedef, it gives a warning for the named constructor, but not the unnamed one.

Adding the public typedef works to remove the warning from the named constructor, the same logic should apply to all static members.

[AzizbekEshpolatov]

typedef Public = _Internal;

class _Internal {
const _Internal();
}

The warning says that a private class is being exposed through a typedef.

Is this expected behavior?
If so, should Dart disallow such typedefs completely at compile-time, rather than allow it and then show a warning?

In my use case, the typedef was only intended for internal structuring, not public API exposure.

Would love clarification or recommendation from the language team — whether this pattern should be avoided or supported with stricter rules.

Thanks!

[lrhn]

The language has no opinion on this. It's a perfectly valid strategy to declare a type with one name and expose it by another name using a typedef. Even if only one of the names is private. (It's sometimes a neat trick to use during an API change.)

The warning comes from the analyzer.
I don't know what the reasoning behind it is, other than exposing a privately named declaration potentially being a mistake (which it was in your case, so not a bad assumption).

It's not definitely an error, so having it as a warning allows you to ignore that warning when you know what you are doing.

[eernstg]

It's sometimes a neat trick to use during an API change

Right — and in general, it allows for encoding a constrained usage of type arguments (including techniques known as phantom types, and more). For example, it can be used to emulate invariance of one or more type parameters of a class.

Consider the following example, where we have a non-covariant member callback which is capable of causing a run-time failure:

// Library 'lib'.

class Public<X> {
  String Function(X) callback;
  Public(this.callback);
}

// Library 'client'.
import 'lib.dart';

void main() {
  Public<int> x = Public((i) => "Hello, $i!"); // OK.
  Public<num> y = x; // No compile-time error, but not safe either!
  y.callback(42); // Throws!
}

The reference to y.callback will throw, we don't even reach the point where this function is invoked.

The real solution is to mark the type parameter X as invariant, but Dart does not support this mechanism (yet). See dart-lang/language#524 for a request to get it.

However, the technique which is discussed here makes it possible to emulate invariance, which turns the dangerous situation into a compile-time error:

// Library 'lib'.

typedef _Inv<X> = X Function(X);
typedef Public<X> = _Internal<X, _Inv<X>>;

class _Internal<X, Invariance extends _Inv<X>> {
  String Function(X) callback;
  _Internal(this.callback);
}

// Library 'client'.
import 'lib.dart';

void main() {
  Public<int> x = Public((i) => "Hello, $i!"); // OK.
  Public<num> y = x; // Compile-time error!
  // ... so we don't need to worry about run-time failures caused by `y`.
}

The point is that we're enforcing that every generic instance of the type _Internal<S, T> which will ever exist has the form _Internal<S, S Function(S)>: Inside the library lib this rule is followed by convention (because the maintainers of that library wish to enforce this relationship). Outside the library lib the rule will be followed because there is no other way to denote any type of the form _Internal<S, T> except when it is expressed as Public<S>.

We definitely don't want to gratuitously eliminate this particular kind of expressive power.