{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif23gh3xztj537m2xzl2lvdcnp7ybzfok4vg4s6nhfycg3fb563i4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mmkghye2rol2"
  },
  "path": "/t/pre-rfc-make-some-feature-detected-function-to-fn-pointer-casts-safe-through-zst-token-types/24353#post_3",
  "publishedAt": "2026-05-23T19:57:18.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "ais523:\n\n> A possible alternative: give the ZST tokens themselves a method that casts from function item to function pointer\n\nI briefly touch on this in alternatives, so thank you for considering it further. I believe a _function_ is going to be considerable headache of its own. At least it does not seem reasonable to provide any useful signature that could be rendered via `rustdoc` for the lack of denoting the ABI-constraints. Even if we _just_ permit casts between the same function args and return types we still have two sets of type generics there where one argument must be `F: impl Fn(A…) -> B + Zst` and the other `fn(A…) -> B`. That just can not be expressed concisely by any syntax (HKTs maybe but that seems absurdly unreadable). Plus I would not mind _not_ having type unificatiom happen here just in case we do later want to permit some ABI casts afterall.\n\nThe best alternative after a night's sleep, acknowedging everything against using the local's existence directly, may be the macro solution where the token type can be explicit and there is no surprise about type oddities. Plus tokens are `Copy`.. Syntax should be no issue (apart from painting the bikeshed)\n\n\n    std::fn_feature_cast!(has_sse, crazy as fn())\n",
  "title": "[Pre-RFC] Make some feature-detected function-to-fn-pointer casts safe through ZST token types"
}