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

libs
21

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
22

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.

  1. Semantically backwards

I am not sure what you mean.

  1. 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.

23

Intrinsics support for bit operations is necessary.

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

1 Like
24

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 :).

1 Like
25

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.

26

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.

27

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!

28

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