[New rule] Avoiding List<Future<T>> in function signature as return type

[PlugFox]

Avoiding List<Future<T>> in public function signature as return type, since this does not make sense and complicates further interaction.

[X] Suggests an alternate way of doing something (suggestion)

BAD:

List<Future<T>> Function
Iterable<Future<T>> Function

GOOD:

Stream<Future<T>> Function

[incendial]

@PlugFox hi, if it's a rule proposal, could you please fill the template like this one: https://github.com/dart-code-checker/dart-code-metrics/issues/391. If it's a change to an existing rule, please add a reference to it.

[incendial]

Also, the motivation behind it is not that clear - if I remember correctly you can Future.wait on a list of Futures.

[PlugFox]

@incendial yeap, you can manipulate Iterable<Future> INSIDE function, but returning Iterable<Future> in PUBLIC function does not make sens.

Static method wait takes Iterable<Future>, not returning.

All the cases that I just saw on the return of Iterable<Future>/List<Future> in public methods - were completely unjustified. I have not seen at all not a single case where it would not have been a mistake.

The result of executing several functions is always Stream or Future, not Iterable<Future>. Iterable<Future> - A list of what needs to be done, not the result of processing. Quick fix for this: Stream<T>.fromFutures(Iterable<Future<T>> functions)

[PlugFox]

Also, Future<Iterable>/Future<List> also has nothing with common reality, and in the overwhelming majority it is a public interface design error.

Streams provide an asynchronous sequence of data.

[incendial]

Static method wait takes Iterable<Future>, not returning.

Yeah, but what is the problem with having a function returning a List<Future<T>> and then a separate place where the result of this function is wrapped in Future.wait, for instance?

Right now it looks like this proposal addresses the problem of misunderstanding of what List<Future<T>> really does, because, as you highlighted, the docs mention that the Stream is for sequence of data and List<Future<T>> is not. So, if I understood your intention clearly, then I don't think that it's a good way to ban such thing as List<Future<T>> just because of misunderstanding.

The result of executing several functions is always Stream or Future, not Iterable<Future>.

IMO, Stream is for sequence of async data. Future, on the other hand, could be used for parallel async data requests, which means that I can use Future.wait or Future.any with List<Future<T>> and it's pretty valid.

I have not seen at all not a single case where it would not have been a mistake.

If you could share some examples, it'd help understand the problem better.

Also, Future<Iterable>/Future<List> also has nothing with common reality, and in the overwhelming majority it is a public interface design error.

Hm, that's also needs an example, because I think Future<List<T>> is pretty common, but maybe I got your idea wrong.