{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiczgdswi5kun2fr7jr6gxigwfrmx5zcayarzlrpher35y63falpia",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mmm743oetpv2"
  },
  "path": "/t/from-text-type-class-to-convert-from-text/14150#post_8",
  "publishedAt": "2026-05-24T13:21:20.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "decodeFS",
    "2295-os-str-pattern - The Rust RFC Book",
    "OsStr is an interface"
  ],
  "textContent": "hasufell:\n\n> `filepath` recommends to **not interpret filepaths returned by the OS API unless absolutely necessary**\n\nMy goal is to write general-purpose applications, and to me “absolutely necessary” means “don’t bother unless you know something extra about the target system”. I therefore assume that the suggested approach is to read/write UTF-8 with no regard for target’s locale.\n\nThis directly contradicts how `base` handles file path handling, which I wouldn’t care much about if the tools given were good enough to replicate what `base` does (with proper error handling, of course). Instead there’s decodeFS, which manages to compress everything I’m trying to escape into a single definition.\n\nhasufell:\n\n> If you are however constructing filepaths out of thin air (e.g. from user input), then you can decide on the shape or form.\n\nThere’s no single “you” here.\n\nLibrary users want to talk about file paths as if they are text, which is fine as long as the conversion is not their direct responsibility.\n\nLibrary writers know that file paths are not text, and that any introspection more complex than “<NUL>, <period>, <slash>, <newline>, and <carriage-return>” requires a choice of encoding. And this choice is unavoidable when, say, parsing command-line options (think e.g. about `bar` in `--foo=bar`).\n\nThis divide cannot be bridged without an additional type that’s platform-independent (unlike `OsString`), but is still possibly erroneous (unlike `String`/`Text`).\n\nhasufell:\n\n> what does it mean to construct a filepath on unix and have a windows system interpret it? Or… what is a reasonable JSON instance?\n\nBoth of these are up to library users to decide, squarely outside of the topic of correct file path handling.\n\nhasufell:\n\n> WTF-8 is used to have a single **internal representation** on both unix and windows.\n\nUsed by… Rust? I have no relevant experience in Rust. When I’m talking about WTF-8 I solely mean how the bytes are laid out in memory, same with UCS2LE.\n\nI hope you’re not getting confused by the fact that Rust has a type called `OsString` and _that_ one seems to be in WTF-8. Their raw file path types are raw arrays, I guess?\nThe documentation is lacking.\n\nhasufell:\n\n> You can see part of the fallout here: 2295-os-str-pattern - The Rust RFC Book\n\nThis RFC looks thoroughly confusing to me. I do think of WTF-8 as “sliceable”, but only within the very narrow limits of the Portable Character Set, which guarantees that the characters are single-byte. This is enough to break down `--foo=bar` without scrutinizing `bar`, but that’s the furthest extent of what I found necessary.\n\nMight well be an issue specific to Rust, seems like OsStr is an interface.",
  "title": "From-text: type class to convert from Text"
}