Post #1887743

2026-04-30 12:04 UTC

@weiznich Unfortunately the `Path` API has a no-alloc conversion from `&str`, so there's no room for a new field. Adding fd there would require stuffing it into the path, which seems hacky and could backfire. The Path isn't good anyway. Can't even store \0 for C APIs nor UCS-2 for Windows. Useless for browser FileSystem APIs (WASM).

Replies (1)

@weiznich@social.weiznich.de 2026-04-30 13:14

@kornel I think there are plans to change the various Range types in an also incompatible way with the next edition. It might be possible to do something similar here as well, at least that would give "us" the ability to change the internal layout in an incompatible way. Yes this would cause a lot of churn as old migrated code would then use something like std::edition_2024::path::Path instead of std::path::Path and likely get a deprecation warning for the old items at some point, but it doesn't seem to be impossible to change it. Especially given that the various std::fs functions all take generic arguments that require AsRef (not sure if we would get away with using the new path there, although I expect it should be fine as long as all currently existing variants are accepted there.). That are obviously all unfinished quick ideas what could be tried. Any of that would need a bunch of research first if it is wanted and then what exactly is feasible and what not.

Open ##1887744