libstd::sys take 2

[arcnmx]

I'm just going to reopen this discussion here because I've been sitting on this for ages and dunno what to do with it. If there's any sort of agreement I can rebase and update it onto master. The end goal here is to move all platform-specific code into libstd::sys, and remove as many #[cfg()] directives from the rest of libstd as I can. This makes libstd cleaner and easier to port to other platforms.

See the internals thread for previous discussions. It's massive, I'm sorry... Would it work better if it were split up somehow? I can do it in chunks as long as the final design is agreed upon as sufficient.

[rust-highfive]

r? @aturon

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

[alexcrichton]

Thanks for the PR! This is such a large change, however, that this falls under the "needs an RFC" category before sending a PR with the changes. If you need any help writing an RFC, however, please just let me know!

[arcnmx]

Internal implementation details require a RFC? I can certainly split it up into smaller chunks for review, or have it land in small manageable parts, but I fail to see why an RFC is necessary or what it would say? It's simply a refactor in order to make porting to new platforms easier. A lot of moving code around but no actual changes.

[alexcrichton]

This is a massive change to libstd, even if organizationally. Lots of people work on libstd and it's architected pretty deliberately today, and in general we prefer to gather feedback about changes like this not on PRs but in other forums like discuss or RFCs

[arcnmx]

Well, libstd::sys already essentially exists for this purpose, it's just less filled out than it should be! I tried generating discussion on discourse/internals and just got not very much feedback. My impression is that not very many people care, but it's an overall net benefit in both organization and ease of portability, so I'd like to see it happen.

The biggest issue is how large the changes are, which can cause conflicts with existing PRs and working branches people may currently have. libstd is relatively stable and quiet right now so I don't see that being a huge problem (and also makes it a good time to implement this change), but landing it in small steps could also help.

I can try and whip up an RFC if you insist, but I can just see that stagnating for months due to lack of discussion/interest/etc. and I'd really like to see it move forward if possible.

[alexcrichton]

Sorry I don't have a lot of time to dig into this much right now, but I know that I at least would benefit from a refresher explaining what's going on here (as it's been awhile since the original PR and the internals thread were opened). I'd personally like to be reminded of:

• The initial motivation
• The detailed design of what movements are happening where (e.g. an explanation of how the diff was generated)
• What this then enables in the future.

That fits the skeleton of an RFC at least, and it may be the case that the @rust-lang/libs team ends up deducing that an RFC wasn't worth it after all and settle on the RFC quickly. (others can feel free to chime in here as well, too)

[aturon]

I agree with @alexcrichton that this kind of substantial change to implementation details needs to go through the RFC process. We need to hash out the tradeoffs involved before landing it.

@arcnmx I know you were worried about not getting enough team attention on the discuss thread, but the libs team tries pretty hard to stay on top of RFCs.

Also, writing up a formal RFC is a good way to drive articulation of the pros and cons of a change.

[brson]

I like the goal of centralizing the plattform-specific parts of std into a porting layer. From a quick browse I think I like where this is going. It is a massive patch to digest though and I agree it needs a lot of consideration, and an RFC is probably prudent.