[hgomersall]

"Color" in this case just means signature. Of course you can't mix signatures - why would you want to? You might as well argue that Rust shouldn't have had any more than a single integer argument to every function. Async in rust essentially desugars to a return trait impl.

[zaphar]

That isn't quite true. An async signature forces it's caller to be async as well. This is because of it's semantics. Most signatures don't infect their callers signatures like that. async is qualitatively different in this regard.

[hgomersall]

No it doesn't. Your can call an async function in rust from anywhere, you just can't await on it outside of an async function.

[zaphar]

The async function also can't await outside of an async runtime. Which means I cant just call it and expect it to work. I need to wrap the call in an executor of some sort. If the async function doesn't do any awaiting itself then it doesn't even need to be an async function.

So in practice my statement stands.

[hgomersall]

But that's true of everything. You can't use a struct except through an "executor" of some sort. Once you've created it, it sits there and does nothing until you exercise it through its methods or other methods that take it. In that case, there's no ambiguity because the type is explicit. I guess the problem is that really `async fn` looks like a function, but isn't really a function, it's a future. The semantics of a future are quite different to the semantics of a function. That's only a problem if you think the semantics of `async fn` should closely reflect a function.

The thing is, once you grok async in rust, other things make sense, like being able to construct futures by implementing `Future` on a struct. You don't actually need `async fn` to do async rust. It's just syntactic sugar, just like await is.

[lcall]

I'm no expert on all the details, but I found you can use (at least with tokio) runtime.block_on() to call async (sqlx) code from non-async (my) code. Ctrl-F to see my other comment about block_on, here.