Pre-RFC: a vision for platform/architecture/configuration-specific APIs

[eternaleye]

“os(windows) & os(linux)” doesn’t either.

Winelib on Linux would be “=windows”, to use my terminology, for one. Cygwin gives Windows + Unix, as does midipix.

And no, such an exhaustiveness requirement would be

1. A huge amount of boilerplate for each crate
2. Semantically backwards
3. Relatively inextensible

[Ericson2314]

winelib, Cygwin, midipix

Fair enough of the principle, but do any of those work like that? Last I checked there is a huge amount of code in std and the community that assumes a unix-windows dichotomy.

1. A huge amount of boilerplate for each crate

Huh? My proposal is that we cfg just like today, but something checks to ensure regardless of the (valid) combination of cfg tokens, there are no unresolved identifiers. The compiler, not the users “proves” that that the cfgs are total. If anything the problem would be compilation time bloat, not code bloat.

2. Semantically backwards

I am not sure what you mean.

3. Relatively inextensible

Do you mean any(os(windows), os(unix)) seems total, but then somebody adds multics to rustc, so the code wasn’t so portable after all? We can avoid that.

[dobenour]

Intrinsics support for bit operations is necessary.

I think that Rust should support all intrinsics that LLVM does.

[Ericson2314]

This may sound goofy, but I’d love to see a scenario where Rc is gone and destructors are guaranteed. Everybody gets to eat their own cupcake :).

[rkjnsn]

I looked at this during the “should forget be unsafe” discussion, and I do believe it should be possible to have destructors guaranteed while having reference counting. (Specifically, the guarantee would be that an object would be guaranteed to be destroyed by the end of it’s valid lifetime.) Rcs containing only 'static data could be used exactly as today, since they would be okay to leak. (Their valid lifetime is “forever”.) Rcs containing non-'static data would either be statically prevented from containing cycles (which would require a way to specify that one lifetime strictly outlives another) or would be used with a scope-guard cycle collector that makes sure any cycles are cleaned up.

[ubsan]

I’m not a big fan of this. It feels “worse than C”. At least in C or C++, you need to #include <platform_specific.h> before using any platform specific APIs. I would rather have any platform specific APIs stuck in some sort of std::sys, which says “if you use these, your code is not guaranteed to compile everywhere”, kind of a thing… I’m not sure, though.

I want Rust code to be, by default, portable.

[alexcrichton]

I’ve posted a follow-up thread to this where I hope to flesh out the concept of scenarios to be a bit more concrete. Feedback welcome!

[aturon]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.