Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do we want to support OsString? #25

Open
supki opened this issue Oct 14, 2024 · 0 comments
Open

Do we want to support OsString? #25

supki opened this issue Oct 14, 2024 · 0 comments

Comments

@supki
Copy link
Owner

supki commented Oct 14, 2024

So, it seems that using OsString in place of Strings can help to avoid some pretty pointless convertions (OsString -> String -> OsString) in the common case of putting filepaths into the environment, assuming people use OsString in the first place.

  1. Do people actually use OsString?
  2. Do they care that there are extra convertions?
  3. This is going to be a breaking change (String is pretty much baked in everything right now)
  4. Where is getEnvironment :: [(OsString, OsString)]? Obviously, we could conjure it up ourselves, but (looking at https://hackage.haskell.org/package/ghc-internal-9.1001.0/docs/src/GHC.Internal.System.Environment.html#getEnvironment) it doesn't sound fun at all. Also, I'd rather someone else maintained a Windows-compatibility layer.

Personally, I don't care that much about it, but it seems that OsString is going to be the way forward, so we'd have to support it eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant