{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibxyqyiikapcllwut2n4rrx3itqxhbwlocn65ijf22gyoqff6mhja",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mk7as4hwozx2"
  },
  "path": "/t/bitslice-or-a-sound-way-to-implement-one/24194#post_2",
  "publishedAt": "2026-04-23T23:41:03.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Why is `bitvec` implemented with a reference instead of a raw pointer like `*const u8` or `*const ()` (alongside a separate length field, and `PhantomData` for the lifetime)? I'll try to keep looking through the `bitvec` repo to figure out the motivation, but a quick look through its `Issues` didn't give me any information.\n\nEdit: even `*const [u8]` ( + `PhantomData` for the lifetime) would work.\n\nbascule:\n\n> Alternatively, if there were `unsafe` APIs that could take apart a fat pointer and put it back together while preserving provenance, but allow the caller to carry along some additional data in the length field, kind of like the `addr`/`with_addr`/`map_addr` APIs for tagged pointers work, that could also do the trick.\n\nI feel like \"raw pointers instead of references\" is precisely this API, unless there's some _critical_ optimization that isn't applied with that solution.\n\nEdit again: ahhhhh, the problem is `Borrow` and friends.",
  "title": "`BitSlice` or a sound way to implement one"
}