{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiawohqkebt564sbyij22lvchau77uv3laqrurml3kfxkvrnimgqgi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml6rwiogkxo2"
  },
  "path": "/t/bitslice-or-a-sound-way-to-implement-one/24194#post_17",
  "publishedAt": "2026-05-06T12:08:14.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "canndrew:\n\n> 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\nThe problem is that even at the assembly level, there's a risk of overwriting neighbouring bits you don't own (unless you use atomic read-modify-write instructions, which are frequently _much_ slower than their nonatomic equivalents) – this doesn't matter in a single-threaded context (because you are overwriting them with the value they already have) but might in a multithreaded context. I think most languages don't expose an easy way to do this because most processors don't expose an easy way to do it, and languages are normally designed around processor functionality.\n\nEven in the single-threaded context, the time paid due to the extra instructions is likely going to be higher than the time saved due to the lower memory usage unless you have a _lot_ of values that aren't a whole number of bytes. In practice, this would only normally come up when you have an array of them (e.g. with a map, the savings would be negligible compared to the size of the keys). As such, it probably makes more sense to have bit-array / bit-slice / bit-vector types specifically rather than bit-references in general.",
  "title": "`BitSlice` or a sound way to implement one"
}