Open
Description
Ideas and tracking to take advantage of “new” features in Rust
All features to be used because of what gain they give us, not to score points. Formulate goal & gain before implementing - and write it up the pull request 🙂.
- std::alloc
- use/namespaced macros - Bump to Rust 1.30, add macros to preludes, and switch macro_use to use #517
- std::arch and
target_feature
I'd prefer significant work in this area to take place in a separate crate, that we depend on. Something that gathers low level "loops" in one place. Like this, but revived and remade - NonZero for nonzero integers
- NonNull for pointers Change ArrayBase.ptr to NonNull type #434
- repr(transparent)
- needs_drop
- pub(crate) - This can be used for reorganization of a quite old crate structure
-
const fn(1.31) - Inclusive ranges
- Rustdoc item links
- 2018 edition path rules Update ndarray to Rust 2018 edition #567
- Run
cargo fmton repository and add format checking to CI (now thatrustfmtis stable). - Possible use of
no_std+alloc. (1.36) no_std for ndarray #708 -
MaybeUninit(1.36) Change uninitialized to return an array of MaybeUninit #685 - Annotations in docs to indicate when items are enabled by features. This requires the unstable doc_cfg feature, so we should probably enable this only on docs.rs. To do so, we can add this to the crate:
#![cfg_attr(docsrs, feature(doc_cfg))]
and then on each item enabled by a specific feature, we add this:
#[cfg_attr(docsrs, doc(cfg(feature = "thefeature")))]
(For an example, see async_compression.)
- Const generics Improvements using const generics #961
Future features (not relevant yet, because they don't exist in stable Rust)
- Variadic generics
- Generic associated types
- Custom DST
- Specialization
- Allocator trait
Iterator::try_fold(Try is unstable) Forward .try_fold(), .try_rfold() on the iterators when possible #706- trait aliases
This is a tracking issue, please edit it.