As a heads up, I have a PR to rename the entire std::io module to std::old_io. As the many I/O RFCs land over time we will be incrementally implementing everything (instead of doing it all in one go). In order to prevent breakage in existing programs all over the place, we are doing one swooping rename today to avoid further breakage down the line.
As replacements for old_io features are implemented they will be #[deprecated] as appropriate. This means that code today needs to rename std::io to std::old_io and then gradually over time you can migrate to std::io as it falls into place.
Hopefully this helps smooth the transition into this brave new world!
Note that, as a contingency, it can always live on as #[unstable] post-1.0, which would effectively hide it from most newcomers (who, we hope, will use beta/stable releases).
I’ve heard some worries about this renaming indicating a complete redesign very close to beta1 – which would indeed be risky! – so I want to clarify.
The renaming to “old_io” is purely to make updating code clearer easier – it does not indicate a massive redesign.
The final API will actually be quite similar to the existing std::io in most respects. It fixes a few longstanding complaints, reorganizes the modules into a flatter hierarchy, and renames to match conventions elsewhere. These are tweaks and polish, not a complete rethink.
Where there are deeper changes (e.g. introducing OsString), we are codifying trends that are already in place (e.g. the env_as_bytes function).
In general, the changes to IO also all make the design more conservative, following traditional APIs more closely, exposing fewer high-level abstractions, and removing questionable APIs.
For most applications, updating will just be a matter of updating names and imports.
Reaching alpha means three things:
The language is feature-complete. All gates are removed from features we expect to ship with 1.0. The standard library is nearly feature-complete. The majority of APIs that will ship in 1.0 stable will already be marked as #[stable]. Warnings for #[unstable] features are turned on by default. (Note that the #[experimental] stability level is going away.)
This is so Mozilla. The old version is deprecated, and the new version doesn’t work yet. This sort of thing is why I stopped writing Firefox add-ons and end-of-lifed most of them.
FWIW, we’re still pre-1.0, which is not an excuse to break things but rather a warning that some things may still break. Although, that’s not expected to happen as much as it previously was.
I appreciate that all API changes are annoying to cope with, even simple renames, but I think we have fairly advertised that these changes were coming. I/O APIs were never marked stable, and were in fact specifically highlighted in the alpha release post under the heading “What remains to be done?”: “IO reform: An overhaul of the IO APIs is being planned; please join in the conversation! These changes will be landing throughout the alpha cycle.” Bear with us a bit longer – we’re not at 1.0 yet.
Also, note that the way this deprecation is being performed (by renaming io to old_io) is to make updating to the new code easier to do incrementally: instead of having to update code for semantic changes in one go, you can just do this “dumb” renaming and then progressively switch to the new functionality.
Another approach would be sliding in the new functionality directly in-place, but this would involve some surprising semantic changes in a few instances. We’re trying to be as helpful as possible.
