"Don't create lambda when a tear-off will do" for generic methods

[zoechi]

Should tear-offs of generic methods work? The analyzer currently can't handle it. It might be better to not report such cases until it is fully supported.

[JPaulsen]

It is probably this bug will take some time since we are not able to check for generics methods, reproduce bugs and create tests yet.

[minikin]

I have the same issue:

library serializers;

import 'package:built_collection/built_collection.dart';
import 'package:built_value/serializer.dart';
import 'package:built_value/standard_json_plugin.dart';
import 'package:my_app/src/services/models/models.dart';

part 'serializers.g.dart';

@SerializersFor([
  Account,
  Customer,
  Product,
  Order,
])
final Serializers serializers =
    (_$serializers.toBuilder()..addPlugin(StandardJsonPlugin())).build();

T deserialize<T>(dynamic value) =>
    serializers.deserializeWith<T>(serializers.serializerForType(T), value);

BuiltList<T> deserializeListOf<T>(dynamic items) => BuiltList.from(
    items.map((item) => deserialize<T>(item)).toList(growable: false)); // Don't create a lambda when a tear-off will do.

[eernstg]

@zoechi wrote:

Should tear-offs of generic methods work?

There is (currently) no support for syntax like deserialize<T> as an expression, but you might be able to use generic function/method instantiation. That is, you just write v.map(deserialize) and then the type argument for deserialize is provided implicitly by type inference:

List<X> foo<X>(X x) => [x];
List<int> bar(List<int> Function(int) f) => f(42);

main() {
  bar(foo); // "bar(foo<int>)", if that had been a thing.
}

That said, it would of course still make sense to adjust the lint such that it does not complain about cases where such type arguments cannot be inferred (e.g., because they are only used in the type of an optional parameter which is not part of the function type expected by the context).

[srawlins]

Note that there is now support for generic method tear-offs. As of Dart 2.15 I believe.