Tagging blocking methods

language design
1

We have a crate for cross-task/thread communication which offers both async and non-async versions of method calls. One thing which has happened a few times is that developers use the non-async version in async scopes.

It would be nice to be able to tag functions so the compiler would warn "This function has an async counter-part, please use that instead" when used in async contexts.

Does some mechanism exist already? If not, is this something anyone else would find useful?

2 Likes
2

I would find this useful, as long as there's an easy way to suppress it on a particular call if you really do need the blocking version.

1 Like
3

The suggested setup

  • there are two related fn-s: async and not
  • presumably with different names
  • there is context tied to lexical scope at caller site: are we inside async fn/block or not?
  • we'd like compiler to aid in selecting the right fn
    • the aid can be as weak as a warning when a wrong fn is used
    • or as strong as selecting the right one to call (somehow)

seems also applicable to floating-point fast-math. Indeed

  • there can be two/three/four versions of sum or sqrt function
  • there can be local context at call site: do I prefer loose math or reproducible math
  • it'd be nice for compiler to aid in selecting the right version of sum or sqrt to call
4

must_use might offer some precedent here -- a bunch of returns-new-thing methods are marked with "did you mean abcd, the edit-in-place version?".

(And there's not really an opt-in the same way for it, but panicking-vs-Option methods might like to have something similar.)

5
1 Like
6 
// explicit-Sync pattern
#[derive(Copy, Clone, ...)]
struct Sync;
fn sync_method(_: Sync, ...)
async fn async_method(...)
fn neutral_method(...)
7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.