Add vision for std::os, a few other tweaks

[aturon]

Here's some text trying to lay out the vision for std::os and lowering a bit more explicitly. I'll also add some questions about the rest of the RFC as comments here.

[aturon]

Some questions/concerns:

General

Right now, the APIs make heavy use of libc types, but the ultimate fate of liblibc isn't clear to me. Have you thought about whether these types might want to be defined in std::os::* instead? If so, I would strongly suggest an organization with raw submodules or some other way of grouping these types.

Lowering Permissions

The vision with respect to mode and bitflags wasn't totally clear to me. Is the idea that at the raw level, we should just expose the native C type always, even when we could have a very thin newtype that is more ergonomic/"safer" in some way?

(To be clear, I think I'm fine with that design, but curious about the overall plan/conventions.)

Constructing Permissions

I don't think new_* is the best convention for these constructors (though new() is perhaps OK... default()?) It feels a bit verbose: Permissions::new_readonly(). But I suppose we want to keep readonly() available for a getter method eventually. Might be worth thinking of further alternatives here.

Why not provide a template method here?

Creating dirs

Why not provide a method of providing a Permissions?

I like the use of builders here and elsewhere in the new IO system. But, I worry that the first step of using a builder is a little wordy: going from create_dir(some_path) to CreateDirOptions::new().create(some_path) feels suboptimal. This might be ok for cases, like std::thread::Builder, where the builder is somewhat uncommon. But I suspect in IO these will be relatively common. An alternative would be to have a free fn that compresses CreateDirOptions::new(). That can certainly be left for later, though.

[aturon]

Overall this looks great, and I'm excited to start bulking up these APIs.

It may be worth noting that, although we're anxious to stabilize these things, the RFC doesn't represent a commitment to do so on any particular timeframe. So despite it covering a large surface, we don't have to actually make the final commitment all at once.

[alexcrichton]

• one raw module
• raw_mode => mode
• don't care about difference in integer widths
• remove template
• don't stabilze builder
• minimalism in raw module
• remove new_readonly

[alexcrichton]

• RawMetadata => Metadata