{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig62sszrahxepzfqsqtapugnyiwt7e3vnbngtgaxgfyqnwcot7sbm",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mmlp7vfoigz2"
  },
  "path": "/t/from-text-type-class-to-convert-from-text/14150#post_6",
  "publishedAt": "2026-05-24T09:20:55.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "BurningWitness:\n\n>   * `filepath` recommends and is structured around blindly assuming UTF-8 under POSIX, addressing (2) and (3);\n>\n\n\nI’m not sure where you have this from, but it’s not correct.\n\n`filepath` recommends to **not interpret filepaths returned by the OS API unless absolutely necessary**. And even in the case where one needs to, you can often get away with assuming specific codepoints (e.g. filepath separator `/` is encoding agnostic and although file extension separator `.` is not in the posix standard, I would recommend to assume the ASCII codepoint here too).\n\nIf you are however constructing filepaths out of thin air (e.g. from user input), then you can decide on the shape or form.\n\nNot every application is a file manager or shell language though. There’s lots of use cases where filepaths are mostly internal and just need to roundtrip correctly. OsPath/OsString helps with this too, since there’s no automatic conversion ever.\n\nThere’s also more interesting questions like: what does it mean to construct a filepath on unix and have a windows system interpret it? Or… what is a reasonable JSON instance? `OsPath` forces you to think about this and I believe there is more than one answer.\n\nIf you only want to support UTF-8 enabled systems in your application, that’s fine too. It should be documented though and you could also do sanity checks on application startup (e.g. checking locale).",
  "title": "From-text: type class to convert from Text"
}