Refactoring std for ultimate portability

jethrogb · 2017-01-07T21:24:56.340Z

Nothing yet and nothing planned for the next month and a half at least, so feel free to start anywhere you want.

panicbit · 2017-07-26T17:51:25.995Z

I’ve been working on something the last few days. I started with std::fs, which was rather trivial to create an abstract layer for (since it’s already pretty cleanly seperated) and I’m currently shuffling around std::net. Would love to hear some thoughts about it.

edit: Whoops, forgot the link: https://github.com/rust-lang/rust/compare/master...panicbit:portability

jethrogb · 2017-07-26T20:44:52.731Z

Neat! I looked over the diff so far and it all looks reasonable to me. The main question I have that you might have a better look at since you’ve touched the code: does this actually reduce the interdependencies such that it could be separated out into a different crate?

panicbit · 2017-07-26T21:13:05.000Z

Yes! I intend to make ::pal an external crate at some point. Interdependencies are supposed to expressed by using associated types on the trait (possibly reusing traits for other modules). ::pal currently depends on ::io::Result and ::time::SystemType, but the former can be moved to ::pal and reexported by libstd and the latter probably will find it’s place as abstraction in ::pal::time.

jethrogb rustlang@discoursemail.com schrieb am Mi., 26. Juli 2017, 22:54:

jethrogb · 2017-07-26T21:20:47.922Z

What about things like std::path?

panicbit · 2017-07-26T21:22:39.129Z

I haven’t looked at std::path yet, but I assume that it should be no different than the other modules.

panicbit · 2017-07-27T15:12:26.886Z

impl Trait in structs would be nice to avoid accidentally calling non-trait methods (especially inherent methods with the same name are a risk)

FenrirWolf · 2017-08-03T23:32:24.161Z

On that note, would all these traits and associated types cause error messages to blow up in complexity for the end-user?

panicbit · 2017-08-04T00:27:23.000Z

The end user? Users of the libstd won’t see any of that and implementors of the backends would at most see a bunch of “this function is missing in this impl for SomeTrait” once per missing function instead of everytime per use of a function. Also, the error messages are generally much friendlier since they’ll also include the types.

system · 2019-03-25T08:27:15.664Z

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