Is there a way to get a OsChar literal more conveniently than osp + head

Keep in mind that OsChar is actually more or less a byte in an encoded byte sequence. You could argue it should have been named OsWord to avoid confusion.

There are cases where extracting an OsChar and pattern matching on it makes sense, e.g. notably with the filepath separator /, because it is encoding agnostic. But in other cases you may get nonsensical results if you expect OsChar to correspond to unicode code points or graphemes even. On windows (UTF-16) you may hit a surrogate or on a utf-8 unix system you may hit a multi byte unicode sequence.

Using unsafeFromChar :: Char -> OsChar and then pack :: [OsChar] -> OsString essentially truncates your unicode to the extended ascii range. You could now treat it as valid latin1 , but it’s unclear if that makes any sense.

If you need proper semantic search, you need to decode first (e.g. to String or Text) and decide what the source encoding is.

The filepath extension char is a bit on the fence here: posix standard doesn’t specify a byte for it, but I believe it’s more or less convention that 0x2E (anywhere in a byte sequence) denotes a filepath extension.

If we look at UTF-8 then it becomes apparent that we can’t accidentally have 0x2E in a multibyte unicode sequence. All bytes in a multibyte unicode sequence always start in the range greater than 0x80 (so above the ascii range). That’s why the encoding is ascii compatible. You can’t get an accidental / or ..

I don’t think that holds for all encodings, but the OS API won’t really care whether your string has a funny encoding. The filepath separator is a fixed byte.