How marker traits works

[diva123]

i don't understand how a marker trait works. These are basically empty that means they don't have any functions associated with it then how does traits like these enforce certain properties on types which implement these. For example lets say i have type T which implements sized which means
that type T size is known at compile time. Since sized has zero method in it, how does rust compiler confirms type T size is known at compile time. Similarly how does rust compiler confirms a type which implementing Send is thread safe.

[jofas]

Great answer here on URLO I think you might find useful:

Understanding the marker traits

There's a few different ideas going on here. In one sense, a marker trait is just a trait that doesn't have any items. Even without any special compiler support, this can sometimes be useful (e.g. sealed traits.) In another sense, there is an unstable #[marker] attribute that you can put on marker traits (in the above sense) in order to opt into the overlapping implementations of RFC 1268 (also unstable). And yet another sense are "the things in std::marker". Most of those things are marker…

[H2CO3]

You seem to be confusing the implementation of a trait with requiring types to conform to such a trait bound.

Magic traits like Sized are implemented by the compiler upon inspecting the structure of a type. (If a type recursively contains unsized types, it's unsized, otherwise it's sized.)

This is completely unrelated to whether or not they have any methods. The Sized trait could as well have an associated method size_of() returning the size; this would not affect how and for what types it is implemented in any way.

How marker traits are used is another question. That's in fact why they are called markers: they don't enable additional methods to be called on a bounded type, they merely mark that type as a member of a particular set, having a particular property.

For example, accepting a type bounded by Send + Sync means that your code can safely access it from another thread (whether it be by value or by reference). This is an important soundness property required for making sure that low-level threaded code remains memory-safe. There is no need for methods on these traits, because implementing types are known to have the thread-safety property merely by implementing the traits, even if empty.