Tracking issue for OpenOptions expansion

[alexcrichton]

Tracking issue for rust-lang/rfcs#1252

Unstable APIs:

• OpenOptions::create_new
• os::unix::fs::OpenOptionsExt::custom_flags
• os::windows::fs::OpenOptionsExt::custom_flags

[alexcrichton]

🔔 This issue is now entering its cycle-long final comment period for tentative stabilization in 1.9 🔔

Some concerns the libs team has, however, about this API are:

• The name may not always convey what's going on here.
• There are perhaps confusing semantics with calls like .create_new(true).create(false). Specifically ignoring some flags may not work out so well.

[alexcrichton]

Ah and to clarify, we're just considering OptionOptions::create_new for stabilization, not the custom_flags methods.

[pitdicker]

The combination of .create_new(true) with .create() and .truncate() was discussed in the pr of rust-lang/rfcs#1252. Clippy now contains a nonsensical_open_options lint that should catch this (but I don't know if checks for this case already). But a name that gives completely no confusion would of course be best :).