{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib67xg6gdzotoggzgnphlfo5rb4waal4y42fmsh2eowvavnbgbuwu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mk7arp4ebhl2"
  },
  "path": "/t/bitslice-or-a-sound-way-to-implement-one/24194#post_4",
  "publishedAt": "2026-04-24T00:00:09.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "For anyone not already aware of roughly what the problem is: Rust basically has a few stable ways of supporting “higher-kinded types” (HKTs), which are families of types, like `Vec` (_without_ a `<T>`).\n\nHere are the three stable mechanisms for HKTs with one lifetime parameter:\n\n  * You can denote the HKT family `&'varying T` with by just `T`, and feed the HKT a `'varying` parameter to get `&'varying T`.\n  * You can use a generic associated type (GAT) like `trait GatHKT { type Apply<'varying>; }`, perhaps to make a `GatDeref` equivalent of `std`’s `Deref`.\n  * You can use higher-kinded trait bounds (like `for<'varying> Trait<'varying>`) to do something insane like my `variance-family` crate — which is thousands of lines of code long — to try to get much more thorough support for lifetime-parameterized HKTs.\n\n\n\nEach of these three options has problems. The first isn’t fully general. The second interacts poorly with higher-kinded trait bounds. The third involves several `unsafe` traits and presumably isn’t fit for `std`.\n\n`std` uses the first option, which means its traits aren’t as general as possible.",
  "title": "`BitSlice` or a sound way to implement one"
}