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
Associated types of a subtrait must always be explicit even when a supertrait implementation implies the subtrait with specific associated types
#40255
Closed
jimmycuadra opened this issue
Mar 4, 2017
· 2 comments
There is a trait A that has many associated types. There are many functions in a program that take a Box<A> only with specific associated types. To avoid having to write out all this boilerplate (including importing all the associated types), I want to create an alias for A with these specific associated types. A type alias cannot work, because you can't do impl Foo for Bar where Foo is a type alias. Let's try subtraits:
traitA{typeAssoc;// Pretend there are several more associated types here to make uses of `Box<A>` inconvenient.}traitB:A<Assoc=()>{}fntakes_b(b:Box<B>){}
This results in:
error[E0191]: the value of the associated type `Assoc` (from the trait `A`) must be specified
--> src/lib.rs:8:19
|
8 | fn takes_b(b: Box<B>) {}
| ^ missing associated type `Assoc` value
This seems like it should work. Note that declaring B this way is valid, as the program compiles if takes_b is commented out.
The text was updated successfully, but these errors were encountered:
Thank you for linking those issues! I wasn't sure how to search for this issue cause I wasn't sure how to phrase the title/question. Closing this as a duplicate.
Imagine the following scenario:
There is a trait
A
that has many associated types. There are many functions in a program that take aBox<A>
only with specific associated types. To avoid having to write out all this boilerplate (including importing all the associated types), I want to create an alias forA
with these specific associated types. A type alias cannot work, because you can't doimpl Foo for Bar
whereFoo
is a type alias. Let's try subtraits:This results in:
This seems like it should work. Note that declaring
B
this way is valid, as the program compiles iftakes_b
is commented out.The text was updated successfully, but these errors were encountered: