{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidid2pzfb2lbnecnu7zwbt7dciil6y7wicz2epvjry66vvze445ym",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkwugfmcv3a2"
  },
  "path": "/t/bitslice-or-a-sound-way-to-implement-one/24194#post_13",
  "publishedAt": "2026-05-03T07:53:33.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "This is definitely only possible with language support. At the assembly level you can overwrite individual bits at a memory address with AND/ORD. But at the library level you're faced with the problem that you can't overwrite neighbouring bits you don't own, and you can't read+update them because they may be uninitialized or be being written concurrently.\n\nIt sucks that seemingly no low-level language lets you manipulate data at bit-level granularity the same way you can at byte-level. (I did look around at some others recently because doing this was so frustrating in rust). Is there actually a hard reason for it? I can only think of bad reasons like:\n\n  * \"Pointers are byte level\" - You could use the top three bits for a bit-offset, or use fat pointers for sub-byte-aligned data.\n  * \"Reading/writing individual bits requires more instructions\" - That'd usually be a small price to pay for better cache utilization, and it's something people would opt-in to by using sub-byte sized types.\n\n\n\nWhat's the good case against it, assuming you were making a rust-like language from scratch and weren't worried about additional complexity or backwards-compatibility?",
  "title": "`BitSlice` or a sound way to implement one"
}