2 ms·

..you're referring to features of the future as if they're instead features of the function?

• littlestymaar 3y ago
  I don't think I understand what you're asking.
  • Izkata 3y ago
    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.
    • littlestymaar 3y ago
      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.