Skip to content

More portable OsString conversion methods, for paths #27657

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

Closed
wants to merge 1 commit into from

Conversation

Diggsey
Copy link
Contributor

@Diggsey Diggsey commented Aug 11, 2015

Existing code-bases often store paths in a platform specific way. For example, 'git' follows the unix convention of accepting arbitrary byte sequences as paths, while windows-only code tends to use TCHAR* or WCHAR* exclusively. Each is fundamentally incapable of storing every possible path on the other platform.

The need arises to be able to interoperate with these libraries without enforcing additional constraints on the paths (for example, it may be necessary to accept invalid utf8 in paths on linux). The existing methods to convert to and from OsStrings are poorly named, only cater to the linux use-case, and additionally have a failure mode which can only occur on windows, resulting in a particularly poor compatibility story on windows.

See #27390 for a very long argument between @alexcrichton and myself on the matter, and why I think this is the best approach to take.

@rust-highfive
Copy link
Contributor

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

@aturon
Copy link
Member

aturon commented Aug 11, 2015

@Diggsey, thanks for your continuing work and arguments on this topic. Since these APIs are pretty contentious, I think a decision is best made through the full RFC process -- both in terms of any new APIs, and also about whether to stabilize or remove the existing API. As such, I'm going to close out both this PR and the original one.

To try to keep the discussion in one place, it'd be better to have a single RFC that covers both alternatives. @alexcrichton plans to write an RFC in favor of the Option-producing version. @Diggsey, would you be willing to write up an "Alternatives" section for that RFC that summarizes your API and arguments in favor of it? @alexcrichton could then include it, credited to you. (We could also do it the other way around.)

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

Successfully merging this pull request may close these issues.

3 participants