You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
Hey everyone,
it would be great if we could have a shorthand for making a trait
Send
only, like this:desugaring to
(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.
The text was updated successfully, but these errors were encountered: