{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaz6udgiqvowyb4o46asg7ecpsfztnvqwhsgdqdq5xj4d5to3vfdq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mpeanil5agl2"
  },
  "path": "/t/negative-trait-bounds-using-feature-specialization/24412#post_4",
  "publishedAt": "2026-06-27T13:58:14.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "The true **sealed trait** language construct is particularly powerful when combined with specialization. It ensures that **all implementations** of the trait—whether they are blanket or specialized—can only be defined within the crate that declares the trait. This effectively prevents any external crate from providing its own specialized impl that could override the original crate's default behavior.\n\nIn contrast, the traditional _private supertrait_ pattern (i.e., `pub trait Trait: private::Sealed`) can prevent new, non‑specialized implementations for external types, but it **fails** to block external _specialized_ impls. The reason is that the private supertrait is often paired with a blanket `impl<T> private::Sealed for T {}` to allow external types to receive the default behavior. However, this blanket impl inadvertently gives external crates a \"pass\" to satisfy the supertrait, enabling them to write a more specific impl that will **override** the default via specialization. Thus, the private supertrait offers only a superficial barrier, while a true `sealed` keyword would enforce a definition‑site restriction that is immune to such override attacks.\n\nThis eliminates the type-equality ambiguity that currently plagues patterns like `where Indirect<T>: CopyImpled<Impled = False>`, and would render the current workaround (e.g., the `Is` trait trick) completely obsolete.",
  "title": "Negative trait bounds using feature(specialization)"
}