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
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.
Copy file name to clipboardExpand all lines: README.md
+11
Original file line number
Diff line number
Diff line change
@@ -31,6 +31,17 @@ trait IntFactory: Send {
31
31
32
32
Implementers can choose to implement either `LocalIntFactory` or `IntFactory` as appropriate.
33
33
34
+
If a non-`Send` variant of the trait is not needed, the name of the new variant can simply be omitted. E.g., this generates a *single* (rather than an additional) trait whose definition matches that in the expansion above:
35
+
36
+
```rust
37
+
#[trait_variant::make(Send)]
38
+
traitIntFactory {
39
+
asyncfnmake(&self) ->i32;
40
+
fnstream(&self) ->implIterator<Item=i32>;
41
+
fncall(&self) ->u32;
42
+
}
43
+
```
44
+
34
45
For more details, see the docs for [`trait_variant::make`].
0 commit comments