Binary instances for OsString, etc.

[hasufell]

In GitLab by @phadej on Jul 17, 2022, 03:04

Where these should be?

1. binary (then binary would depend on filepath)
2. filepath (then filepath would depend on binary)
3. somewhere else? (https://hackage.haskell.org/package/binary-instances or new filepath-binary-instances).

I don't know if how GHC serializes its stuff, but I bet there are filepaths in there. (Cabal does, and uses Generics). So that rules out third option, except if it's a new filepath-binary-instances package which is bundled with GHC.

Otherwise I'd prefer second option, so the type-class providing package stays as dependency-light as possible.

ping @bgamari

[hasufell]

In GitLab by @maerwald on Jul 17, 2022, 04:12

To me it seems fine if binary depends on filepath.

What would the instance actually do? Just unwrap the underlying ShortByteString? Remember that we have two different constructors for unix and windows:

newtype WindowsString = WindowsString ShortByteString

newtype PosixString = PosixString ShortByteString

newtype OsString = OsString
#if defined(mingw32_HOST_OS)
  WindowsString
#else
  PosixString
#endif

Should you be able to encode on unix, send the bytestring over the wire and decode on windows? What are the semantics?

[hasufell]

In GitLab by @phadej on Jul 17, 2022, 04:17

To me it seems fine if binary depends on filepath.

It's not. filepath is already dependency heavy: through exceptions it depends on mtl, transformers, and stm. IMO adding binary to the list is ok.