Consider adding `always_declare_return_types`

[vincevargadev]

Describe the rule you'd like to see added and to what rule set

I'd like to see always_declare_return_types included in the rules.

To what rule set? Ideally core (but I'll take whatever I can get 😸).

If there is a good reason not to include this rule, it would be great to document that, I couldn't find why it isn't included.

Additional context

• It is included in the "community" passsy/dart-lint (lint)
• It was included in google/pedantic

I've seen this rule mentioned in the following issues, but I didn't see any of these issues actually addressing why this rule is no longer included, it looks to me that it was simply dropped without any explanation

• https://github.com/dart-lang/lints/issues?q=is%3Aissue+always_declare_return_types

[lrhn]

I don't think it's something we should add.

We do have the "type public API" lint in the recommended set (I think, or is it just the flutter lints?), so this is only really about local and private functions.

At that point it's no longer a recommendation about public API, so it would be because omitting types of particularly error prone.

I don't think it is. Local inference is more efficient than top -level inference, and if getting dynamic is a problem, that's what "strict inference" is for.

It's a perfectly good lint for enforcing a particular style, which some people may prefer, but it's not the official Dart style, so we shouldn't be enforcing it in the official lints.

[devoncarew]

cc'ing in @natebosch and @goderbauer for thoughts as well

[natebosch]

I don't think this applies to local functions does it? Edit: it does apply.

I think I'm in favor to help avoid the implicit dynamic until we nail down the strict dynamic lints, but I'd be on board for waiting until that happens instead.

Edit: There is one place where this doesn't involve an implicit dynamic which is then even more of a style question - overrides can safely omit return types.

I'd still be OK with adding this to recommended.