Add a new wasm32-wasip2 target by rylev · Pull Request #119616 · rust-lang/rust (original) (raw)

I think the breakage and what to do can go both ways, so at least in my mind there's not a clear-cut answer of what the best route here is. As you've pointed out a con of changing target_os is that all existing code will need to be updated. This includes code which doesn't interact with wasi_snapshot_preview1 imports directly, such as path-related functionality that you're talking about. A pro, however, is that a new string acknowledges that wasi_snapshot_preview1 is no longer natively supported and is now required to go through an "adapter" and it's best to use component definitions directly.

To me one way to go about solving this is to ignore historical precedent (e.g. the preexisting wasm32-wasi target), decide on a solution, and then see if it can be worked into today's systems. In that sense the preview1 and preview2 targets represent entirely different "OS" definitions (the term "OS" here is a bit loose granted). They're entirely separate embedding APIs which overlap in functionality but to me it's similar-ish to Windows vs Unix. Both have the ability to open a file and such but have very different ways of going about it. Similarly preview1 and preview2 can both open files but behave pretty differently in terms of the fine details (e.g. something that's ignored from the I'm-using-libstd perspective but matters a lot if you're programming directly against the interfaces).

Given all that I at least personally think it makes sense to have different target_os strings. Not to say there aren't similarities to the two targets, however. As you've pointed out the structure of paths being byte-based things with / separators is shared in common across the two targets. This I think is solid motivation for target_family or some similar cfg. That way code can be written to span both.

If you'll continue to walk this hypothetical with me, the next question is that if this state of affairs is desirable does it make sense to retrofit onto the existing ecosystem. Personally I think so. The new component-based target is "new enough" that I'm not sure it's worth it to keep everything working seamlessly as much as possible. This is a good opportunity to rethink what WASI support means and how best to support it. For example libc support is changing, the standard library's platform-specific extensions are changing, the capabilities of the platform are different, etc. All existing code will continue to work for preview1 but code will need to be explicitly ported to preview2.

That's at least my thinking, although I don't know how best to resolve this still myself. I personally think it's best to go with target_os, but I'm certainly not the only stakeholder here!