Blocking on the future isn't a feature of the function that you asked about, and in fact as a comparison to javascript if you expand the example to include an `await` on the returned promise (and include something that's actually async) it also blocks to wait for a result in the same thread. Those are features of the future/promise, not features of the function.
I'm still unsure of what you mean. Of course blocking on the future is a property of the function! The future/promise can exist everywhere, including in non-async functions. The key difference with async functions is that you can block the execution flow on await and only them can do that. Futures/promises cannot by themselves.
But calling await on a future doesn't necessarily mean it will in fact block the flow of execution, it can also return the value instantly (which means it doesn't fit your previous definition of non-blocking function), but it's still a special function that needs to be handled like any other non-blocking function (you can't just call it to get the result, you need to “unwrap” the future by calling await on it).
What I pointed out is that your definition of the split between non-blocking and blocking function is inconsistent and the reason why it is is because you fundamentally get the non-blocking/blocking difference backwards. And that's not your fault actually, the syntax used in pretty much every language leads to this confusion if you don't take a step back and think about it.
