{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihg25oovi44aajoz6zvubl5hhhhvoxkixig5o443m6py5kemjohku",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfxrixd2hji2"
  },
  "path": "/t/what-s-where-size-kind-extra/23987#post_11",
  "publishedAt": "2026-02-27T00:10:11.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[playground]"
  ],
  "textContent": "daniel-pfeiffer:\n\n> Alas both pairs generate differing asm, so guess it’s not zero cost.\n\nI'm seeing the first pair of indexing generate identical asm output for both, just loading a constant. Are you sure you checked with release optimizations? (Alternatively, if you just chucked both options in the same function, was it just trivial register allocation differences?)\n\nThe second pair it makes sense that they differ, since thanks to the `black_box` optimization barriers you used, you're effectively comparing `<[u8] as PartialEq<[u8]>>::eq` and `<[u8; 10] as PartialEq<[u8; 10]>>::eq`. If you tell the compiler to ignore that it knows the slice length, of course it's going to be unable to unroll a loop it doesn't know is fixed length.\n\nA more fair comparison to non-`black_box` usage would be `black_box(ArrConcat([65u8; 9], [65])).as_slice() == black_box(ArrConcat([65u8; 9], [65])).as_slice()`, which moves the `as_slice()` outside of the black box boundary. This _does_ still generate slightly different asm, but it looks to me to be just a trivial difference in register allocation and spill order.\n\n[playground] (choose \"show assembly\" in the run drop-down menu)",
  "title": "What’s where [(); SIZE + Kind::EXTRA]:?"
}