Refactoring std for ultimate portability

[naicode]

I would love to see a future where everyone uses rust, or at last one where it is much easier to port rust to new platforms .

Wrt.:

@DanielKeep

This brings to mind a thought I had a while ago for a new kind of crate that formally supports the kind of dependency inversions at work here. Basically, crates with "parameters" that allow the dependents to inject behaviour into the dependees.

and

@jethrogb

Here I'll plug an idea/question I had last week. I think traits are great! But not all API's are well-represented by traits. I think the compiler or some linter should support some form of "header files" that source files can be checked against. These header files should initially be automatically generated from the publicly reachable items in a crate. This tool is useful here for defining a PAL API, but I imagine it can also be useful to enforce stability guarantees on APIs.

some bikshedding/idea

I think both can be done with some think like singular (module?) interfaces , basically interfaces, which have exact one implementation chosen at compiler time at any time (ignoring the "multiple versions of the same crate" case). They can't be used wrt. generics but are only meant to say (at module level?) that some think of a certain structure exists (applicable to structs, enums, modules etc. inclusive possible partial variations of them). A crate could require such a interface to be satisfied (through other crates, possible depending on this crate) or could provide a implementation satisfying.

EDIT: just to clarify singular interfaces are also not meant to be used as trait objects (they are no traits) and don't have to specify the complete public interface the implementation satisfying them has, partial is ok as long as it doesn't conflict.

And while I think such interfaces would be nice for some cases of dependency inversion in combination with platform specify code I'm not sure if I would want see usage of it outside of this cases. And both the UI case and the test harness case mentioned by @DanielKeep can be solved differently, I think.