{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiciq22njx6kqrvgr5tdw7z72pu4qtn7cctvsueuug4qgwdynmittu",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3miu6hxxzemx2"
  },
  "path": "/t/rfc-mutable-records-as-a-ghc-extension/13886#post_7",
  "publishedAt": "2026-04-06T07:28:56.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "AntC2:\n\n> I agree the `HasField` and friends/‘update’ mechanisms are just too perplexing to be worth using.\n\nI guess for record access specifically the coherent approach would be only have access to field labels once a relevant constructor has been scrutinized, but then that creates a non-type that is “the record inside the constructor”, which can’t be passed to functions. This explains why `NamedFieldPuns` and `RecordWildCards` extensions are structured the way they are.\n\n~~Perhaps it would make sense to think of record syntax as a special type, much like`MutableLayout` of this proposal, so that it can be repackaged into a separate type if passed to a function, otherwise the reallocation is somehow elided.~~ _[After thinking about it some more this would introduce way more problems than it would solve]_\n\n_Actually, the record doesn’t need a special type, it could be represented by a`newtype` over the original type with the relevant constructor name on the type level. Have it be only obtainable by pattern matching with a special extension, have `getField` retrieve the relevant field unsafely._\n\nAnyway, this proposal isn’t about changing the record syntax for ADTs, we shouldn’t focus this hard on that.",
  "title": "[RFC] Mutable records as a GHC extension"
}