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

std::fs::path::Path should probably use a ByteArray instead of a String #314

Open
yorickpeterse opened this issue Jan 26, 2022 · 3 comments
Labels
accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers std Changes related to the standard library

Comments

@yorickpeterse
Copy link
Collaborator

String requires its data to be valid UTF-8 and replaces invalid sequences with a replacement character. File paths in turn don't necessarily need to be valid UTF-8. As such, we should probably change the underlying storage of Path from a String to a ByteArray.

@yorickpeterse

This comment was marked as outdated.

@yorickpeterse
Copy link
Collaborator Author

On second thought: using a String may not be so bad, as most Unix tools seem to assume paths are UT-8 anyway. E.g. Gnome Files shows encoding errors in file names that contain invalid UTF-8. Internally the VM uses strings for paths as well, and I'm not sure from the top of my head what we'd use there as an alternative.

@yorickpeterse
Copy link
Collaborator Author

yorickpeterse commented Nov 16, 2023

We need to figure out the following:

  1. What do different OS'/DEs do when a file path contains invalid UTF-8 sequences?
  2. What do different languages use to back their path types if they have any?

Since this is something contributors can take care of, I'll add the "accepting contributions" label. The actual code changes however need to be discussed first (as in, we need the data first, then we can look at the code), so we can figure out what the impact will be. This way we can avoid somebody submitting a big PR, only for it to be rejected (e.g. because I feel the changes can be done differently/better).

@yorickpeterse yorickpeterse added the accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers label Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers std Changes related to the standard library
Projects
None yet
Development

No branches or pull requests

1 participant