Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a Shorthand for adding Send bounds #18

Open
shadowcpy opened this issue Dec 26, 2023 · 1 comment · May be fixed by #30
Open

Provide a Shorthand for adding Send bounds #18

shadowcpy opened this issue Dec 26, 2023 · 1 comment · May be fixed by #30

Comments

@shadowcpy
Copy link

Hey everyone,

it would be great if we could have a shorthand for making a trait Send only, like this:

#[trait_variant::only_send]
pub trait SomeTrait {
  async fn hello() -> i32;
}

desugaring to

pub trait SomeTrait: Send {
  fn hello() -> impl Future<Output = i32> + Send;
}

(no second variant)

The rationale behind it being that with the mostly Multithreaded Executors that are used widely right now (like tokio), this will probably be the default case once AFIT is becoming stable on 28th.

@GoldsteinE
Copy link

One more data point for rationale: rust-analyzer would generate async fn implementation methods with #[trait_variant::only_send], but -> impl Future<Output = i32> + Send methods with manually specified RPITIT.

traviscross added a commit that referenced this issue Feb 10, 2024
Let's say that we want to create a `Send` variant of a trait but we
don't need a non-`Send` variant of that trait at all.  We could of
course just write that trait, but adding the `Send` bounds in all the
right places could be annoying.

In this commit, we allow simply omitting the new variant name from the
call to `make`.  When called that way, we use the name from the item
to emit only one variant with the bounds applied.  We don't emit the
original item.

For completeness and explicit disambiguation, we support prefixing the
bounds with a colon (but giving no variant name).  Similarly, for
completeness, we support giving the same name as the trait item.  In
both of these cases, we just emit the one variant.  Since these are
for completeness, we don't advertise these syntaxes in the
documentation.

That is, we now support:

- `make(NAME: BOUNDS)`
- `make(NAME:)`
- `make(:BOUNDS)`
- `make(BOUNDS)`

This resolves #18.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants