You need to express a property of a type that adds no operations — 'instances may be moved between threads', 'this may be persisted'. Compare expressing it as an empty interface, as metadata such as an annotation or attribute, and as a compile-time predicate.

## The shape of the problem Some facts about a type add no operations: it is safe to move to another thread, it may be persisted, it is a legal cache key, its values are immutable. Each is a **predicate over types** — a yes/no fact — and languages offer three quite different places to put it. ## Option 1: the empty interface Declare a type with no members and have conforming types implement it. Java's `Serializable` and `Cloneable` are the canonical examples. What it buys: the property lives in the type system. The compiler can check it at a parameter position, and in C# it can serve as a **generic constraint** (`where T : IMyMarker`), which is something metadata simply cannot do. What it costs, and this is the interesting part: - **Only the author may declare it.** A third-party type that genuinely has the property cannot be marked, unless the language allows retroactive conformance. - **It is inherited, and inheritance is the wrong propagation rule for most such predicates.** A class implementing `Serializable` has a subclass that adds a socket or a thread field. The subtype still satisfies the marker — subtyping says so — and serialization fails at run time. The predicate depends on the type's *contents*, but the marker propagates by *hierarchy*. That mismatch is the core defect of the pattern. - **It clutters the type's declared identity** with facts that are not roles. ## Option 2: metadata (annotation or attribute) Attach a label rather than a supertype: a Java annotation, a C# attribute, a Python decorator that sets a flag. Metadata can be applied more precisely (fields, parameters, methods), can carry arguments, and can be defined with a retention or targeting policy. The cost is that plain metadata is invisible to the type checker. Enforcement moves either to **reflection at run time**, which is late and only covers paths you execute, or to a **compile-time processor or analyzer**, which is early but is extra machinery each project must run. Metadata also cannot appear in a generic constraint, so the compiler cannot reject a call site that supplies an unlabelled type. ## Option 3: a compile-time predicate Do not put the fact on the type at all; ask a question about it. **C++** does this pervasively: `std::is_trivially_copyable<T>`, `std::is_nothrow_move_constructible<T>`, and, since C++20, concepts that constrain templates on such predicates. Because it is a query, it works for types you did not write, for primitives, and for instantiations of templates — none of which can be made to implement your interface. **Rust** takes the strongest version. `Send` and `Sync` are *auto traits*: the compiler derives them structurally from a type's fields. A struct whose fields are all `Send` is `Send`; put an `Rc<T>` inside and it stops being `Send`, automatically, with no declaration anywhere. Where the derivation is too conservative — a type whose safety comes from an invariant the compiler cannot see — you write `unsafe impl Send for T`, which is both an escape hatch and an auditable marker of exactly where a human took responsibility. The property is therefore computed and revoked automatically, which is precisely what the Java marker cannot do. **Go**'s position is a useful negative case: an empty interface is satisfied by *every* type, so it cannot mark anything at all. Go instead achieves a related goal — sealing a set of implementations — with an interface containing an **unexported** method, which only types in the declaring package can supply. ## Choosing Ask three questions. 1. **Does the property follow from the type's structure?** If yes, a derived or computed predicate is right, because it will stay correct as the type changes — Rust's model. A declared marker will drift. 2. **Does the compiler need to enforce it at a call site?** If yes, you need something the type system can see: a marker interface as a generic constraint in C# or a concept in C++. Metadata will not do it without a custom analyzer. 3. **Must it apply to types you do not own?** If yes, rule out anything requiring the author's declaration; you need a predicate, a retroactive conformance mechanism, or a wrapper. A fourth consideration is auditability: `unsafe impl` in Rust and a suppression annotation elsewhere are valuable exactly because they are greppable. A design where the escape hatch is invisible — for example, silently inheriting a marker — is worse than one where it is loud. ## The pattern to avoid The failure mode is a marker interface for a property that depends on the type's contents rather than its role, applied in a hierarchy where subtypes add state. The type system says yes, the runtime says no, and the gap widens quietly with every subclass. If the property can be invalidated by adding a field, do not encode it as a supertype.