The reference uses this in a number of places. For example
"A trait object is an opaque value of another type that implements a set of traits. "
Opaque reference and opaque type are also used elsewhere in the reference.
Thank you!
In general, it means that there is some information that the code which possesses the opaque value cannot make use of. For example, if you have a trait object, you cannot access the fields of the value that you might be able to if you had the original concretely-typed value the trait object was made from.
3 Likes
Thank you for the response. That is very helpful.
Is concretely typed the opposite of opaquely typed?
Is a value that is "opaquely typed" = an "opaque value"?
“Opaque” is not a single thing in Rust, and “opaquely typed” isn't a concept in Rust. The reference is telling you that trait objects are opaque about what concrete type they were made from, but that just means that, given a value of a trait object type, you cannot find out the concrete type (except by specific means such as dyn Any). We could equally well say trait objects “encapsulate” or “hide” their concrete types. It's a choice of English word to try to communicate an idea, not part of the formal terminology of Rust.
1 Like
There is "opaque type" as part of the technical terminology of Rust, and it's the return type of a fn() -> impl Iterator<Item=u32>.
This technical usage should be distinguished from the colloquial usage when describing dyn Iterator<Item=u32> 
2 Likes
These are not the same?
Thank you all so much for the responses!
No, an impl XxxTrait is either an opaque return type, or a generic type bound when used for a function parameter type. Whereas dyn Trait is a trait object. All three are different.
An impl Trait in return position is called "opaque" in the compiler because the true type of the value is known to the compiler, but hidden from the programmer to assist in library evolution.
A dyn Trait anywhere has its true type hidden to both the compiler and the programmer, so it's arguably more "opaque" but the compiler doesn't need special rules to hide what the type is, so there's no technical terminology around it.
3 Likes
"Type erasure" is the terminology I've seen used for dyn Trait the most often. The implementing (or "base") type gets erased when coerced to dyn Trait.
3 Likes
Does this have to do with the compiler generating a function per type combination across invocations?
Thank you all so much!
dyn Trait is also opaque in the sense that the layout of the fat pointer is not stable , and AFAIK, it is undefined behavior to transmute a &dyn Trait to an object pointer and a vtable pointer. The layout of the vtable itself is also not stable, so user code can't rely on it.
It's possible to pull out the vtable pointer using things like wrapping_byte_add and the guarantees that passed FCP. (And you can just use casting to get the data pointer.)
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.