{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibwykn7yhda4rfjigu5sen3rupeexnde6u7uluzhr4qtzij3vq55a",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mpdgzzlkjlv2"
  },
  "path": "/t/can-noinline-fail-to-prevent-inlining/14324#post_8",
  "publishedAt": "2026-06-28T07:03:18.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "Right, for your use case OPAQUE should be no less “fragile” than NOINLINE.\n\nThe goal of OPAQUE is: that every call of `f` generates, well, a call of `f`, not of some name-mangled variant.\n\nSo the property it provides is something only GHC API users and those trying to create minimal reproducers for GHC bugs, the people interested in the “syntax” of the intermediate Core representation, should really care about.\n\nFor everyone else, there should be no difference in the “semantics” of the intermediate Core representation between NOINLINE and OPAQUE, except that OPAQUE is likely to give you worse performance when GHC optimizations are turned on. Precisely because OPAQUE prevents certain optimizations that NOINLINE does allow.\n\nI would even go as far as saying that I would consider it a GHC bug when the semantics of your code are as intended when you use OPAQUE, but not when you use NOINLINE; even in the face of unsafePerformIO.",
  "title": "Can NOINLINE fail to prevent inlining?"
}