Separate warnings for None-returning functions/methods without annotations

[gdude2002]

Description
It would be nice if flake8-annotations could tell the difference between a callable returning None or using return for flow control, and functions that actually return a value.

Rationale/Use Case
I was surprised to see this behaviour at all at first, although it makes sense now that it's been explained to me.

• Having a separate error code and message specifically mentioning None returns helps to clarify that this is an intentional part of the project's code style
• Doubtless, there are projects out there that would rather not annotate a None return type (even though this doesn't apply to any Python Discord projects)

---

Good work on this plugin, by the way. It never occurred to me how useful something like this would be!

[sco1]

It's certainly an interesting concept but I don't think this is feasible from within flake8's framework for anything but trivial examples.

The case of cross-file function calls is particularly problematic since flake8 operates on a per-file basis and provides no mechanism to persist information globally for the package being linted, so there is no deterministic way for this plugin to tell if a foo() in return foo() returns anything or not. I'm not comfortable with making the assumption that foo() in this case returns something other than None just because it's being called during a return.

[gdude2002]

That's an interesting point, and I'm not sure if there could be a decent solution to that one - static code analysis tools generally are expected to operate on single files regardless.

I personally feel like assuming the foo() in return foo() doesn't return None is a fairly safe assumption however, as the use-cases for return being used in this manner while foo() only ever returns a None value are extremely limited - but you probably have a better idea than me of the impact of such an assumption.

[sco1]

After doing some more trawling around the internet I'm still against providing this as the default behavior due to its ambiguity and lack of a deterministic way to statically identify whether the function does or does not explicitly return something.

However, since we already make similar anti-PEP484 concessions for style by providing the capability to suppress missing return annotations by function type, it's worth exploring the level of effort required to add a configuration option that allows suppression of TYP200 level errors if a function either:

• Has a bare return
• Lacks a return statement