mirror of
https://github.com/rust-lang/rust.git
synced 2025-04-28 02:57:37 +00:00
Remove outdated Changing directory.
This commit is contained in:
parent
be3d390cf5
commit
48c90a38c1
@ -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)
|
||||
|
@ -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.
|
@ -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.
|
@ -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
|
@ -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
|
Loading…
Reference in New Issue
Block a user