3 ms·

> I still think you should be able to declare async at the call site, not the function site This is the big point. I'd love to see anyone put forth a concrete,

> I still think you should be able to declare async at the call site, not the function site This is the big point. I'd love to see anyone put forth a concrete, valid reason why this couldn't be implemented, because as it stands, it appears that the function coloring problem is exclusively due to poor language design, rather than a technical limitation (where an example of a technical limitation would be escape analysis, which is hard).

henrydark 5y ago
I think the CPS attempt in Nim could do this https://github.com/nim-works/cps https://github.com/nim-works/cps
jayd16 5y ago
Explicit await and promise semantics are useful incase you want to, say, start multiple async calls instead of awaiting one and then the other. But ok, lets say you just want await to be implicit in some cases... Do you actually want this? Currently, you can assume that a function will not change threads mid execution, and that that thread will also not be used to execute other things. Implicit yielding breaks that assumption. Cooperative multithreading becomes impossible because it's much hard to reason about when a method call will yield execution or not.
- throw10920 5y ago
  I wasn't proposing implicit async/await. I was proposing declaring those at the call site, instead of per function declaration.
Rusky 5y ago
Ironically escape analysis is the one thing Rust went above and beyond to solve in a novel way.
- throw10920 5y ago
  No, Rust did not solve escape analysis - it was designed to constrain valid programs to those for which escape analysis is trivial (as evidenced by unsafe Rust, which doesn't have those constraints, and yet has nothing else enabling escape analysis). That's like saying that "C solved type inference" - no, it just constrained you to write your types by hand, and then did some checking of them afterward.

henrydark 5y ago

I think the CPS attempt in Nim could do this https://github.com/nim-works/cps https://github.com/nim-works/cps

jayd16 5y ago

Explicit await and promise semantics are useful incase you want to, say, start multiple async calls instead of awaiting one and then the other. But ok, lets say you just want await to be implicit in some cases... Do you actually want this? Currently, you can assume that a function will not change threads mid execution, and that that thread will also not be used to execute other things. Implicit yielding breaks that assumption. Cooperative multithreading becomes impossible because it's much hard to reason about when a method call will yield execution or not.

throw10920 5y ago
I wasn't proposing implicit async/await. I was proposing declaring those at the call site, instead of per function declaration.

Rusky 5y ago

Ironically escape analysis is the one thing Rust went above and beyond to solve in a novel way.

throw10920 5y ago
No, Rust did not solve escape analysis - it was designed to constrain valid programs to those for which escape analysis is trivial (as evidenced by unsafe Rust, which doesn't have those constraints, and yet has nothing else enabling escape analysis). That's like saying that "C solved type inference" - no, it just constrained you to write your types by hand, and then did some checking of them afterward.