Auto merge of #29080 - Havvy:remove_doc_style_changing, r=alexcrichton

Fixes issue #29077.

There **are** API changing guidelines in the RFCs, so it might be prudent to put those there. But I'm leaving that up to another person. This PR just removes bad documentation.

src/doc/style/SUMMARY.md

@@ -48,7 +48,3 @@
 * [Testing](testing/README.md)
     * [Unit testing](testing/unit.md)
 * [FFI, platform-specific code](platform.md)
-* [APIs for a changing Rust](changing/README.md)
-    * [Pre-1.0 changes](changing/pre-1-0.md)
-    * [Post-1.0 changes](changing/post-1-0.md)
-    * [Timing unclear](changing/unclear.md)

src/doc/style/changing/README.md

@@ -1,5 +0,0 @@
-% API design for a changing Rust
-
-A number of planned Rust features will drastically affect the API design
-story. This section collects some of the biggest features with concrete examples
-of how the API will change.

src/doc/style/changing/post-1-0.md

@@ -1,12 +0,0 @@
-% Post-1.0 changes
-
-### Higher-kinded types
-
-* A trait encompassing both `Iterable<T>` for some fixed `T` and
-  `FromIterator<U>` for _all_ `U` (where HKT comes in).  The train
-  could provide e.g. a default `map` method producing the same kind of
-  the container, but with a new type parameter.
-
-* **Monadic-generic programming**? Can we add this without deprecating
-  huge swaths of the API (including `Option::map`, `option::collect`,
-  `result::collect`, `try!` etc.

src/doc/style/changing/pre-1-0.md

@@ -1,17 +0,0 @@
-% Pre-1.0 changes
-
-### `std` facade
-
-We should revisit some APIs in `libstd` now that the facade effort is complete.
-
-For example, the treatment of environment variables in the new
-`Command` API is waiting on access to hashtables before being
-approved.
-
-### Trait reform
-
-Potential for standard conversion traits (`to`, `into`, `as`).
-
-Probably many other opportunities here.
-
-### Unboxed closures

src/doc/style/changing/unclear.md

@@ -1,28 +0,0 @@
-% Changes with unclear timing
-
-### Associated items
-
-* Many traits that currently take type parameters should instead use associated
-  types; this will _drastically_ simplify signatures in some cases.
-
-* Associated constants would be useful in a few places, e.g. traits for
-  numerics, traits for paths.
-
-### Anonymous, unboxed return types (aka `impl Trait` types)
-
-* See https://github.com/rust-lang/rfcs/pull/105
-
-* Could affect API design in several places, e.g. the `Iterator` trait.
-
-### Default type parameters
-
-We are already using this in a few places (e.g. `HashMap`), but it's
-feature-gated.
-
-### Compile-time function evaluation (CTFE)
-
-https://github.com/mozilla/rust/issues/11621
-
-### Improved constant folding
-
-https://github.com/rust-lang/rust/issues/7834