This, I think, is the biggest portability wart in std. path::Prefix
is Windows-specific and cannot be expanded. This has just bitten us because Redox has path prefixes, and they cannot be represented in std today (see my comment on the redox std pr for details).
So I would like to solve this problem, but I’m not sure how. Here are a few ideas:
-
Produce a patch that opens
Prefix
to expansion with an unstable__NonExhaustive
variant and run it through crater to see the fallout. If somebody else produces the patch I’ll do the crater run. I think we should probably do this regardless of any other solution - it’s more correct for this enum to be open. -
Commandeer an existing variant and document that it is used for multiple purposes. @jackpot51 already produced a patch that does this but it was slightly more intrusive than I expected, and it’s also a slightly distasteful decision to make. One outcome of this decision would be that there is no way to distinguish a Windows-specific path from a Redox-specific path. Personally that does not worry me too much because I contend that Path is not a portable data type, is only meaningful relative to the local system it was produced on.
-
Somehow rework the path internals to store some new side information that is invisible to the current public API; introduce a new API that can access the redox prefix. From just a quick look this seems difficult and would require lots of internal refactoring. Ultimately, this could be equivalent to deprecating the current
components
API and introducing acomponents2
API. -
Use conditional compilation to make new variants appear only on their platforms. There’s not a lot of precedent for this, but one could imagine it might be done with additive scenarios. Maybe some future platforms require the “open Prefix” scenario (handwave).
I do think this is a problem that must be solved somehow. Any opinions about the above, or other bright ideas?
cc @rust-lang/libs @jackpot51