Note: 0.17.0 was yanked due to a bug in the reference type implementation that could cause use-after-free. That bug was fixed in 0.17.1. All the changes listed here are once again available in 0.17.1, with a small caveat for the reference types. See the release notes for 0.17.1 for details.
Version 0.17.0 introduces a new array reference type — the preferred way to write functions and extension traits in ndarray. This release is fully backwards-compatible but represents a major usability improvement. The first section of this changelog explains the change in detail.
It also includes numerous new methods, math functions, and internal improvements — all credited below.
A New Way to Write Functions
TL;DR
ndarray 0.17.0 adds new reference types for writing functions and traits that work seamlessly with owned arrays and views.
is powerful but verbose and often hard to read. Version 0.17.0 introduces a new, simpler pattern that expresses the same flexibility more clearly.
Solution
Three new reference types make it easier to write functions that accept any kind of array while clearly expressing what kind of access (data or layout) they need.
Reading / Writing Elements: ArrayRef<A, D>
ArrayRef is the Deref target of ArrayBase. It behaves like &[T] for Vec<T>, giving access to elements and layout. Mutability is expressed through the reference itself (& vs &mut), not through a trait bound or the type itself. It is used as follows:
LayoutRef lets functions view or modify shape/stride information without touching data. This replaces verbose signatures like:
fn alter_view<S>(a: &mut ArrayBase<S, Ix1>)
where S: Data<Elem = f64>;
Use AsRef / AsMut for best compatibility:
fn alter_shape<T>(a: &mut T)
where T: AsMut<LayoutRef<f64>>;
(Accepting a LayoutRef directly can cause unnecessary copies; see #1440.)
Reading / Writing Unsafe Elements: RawRef<A, D>
RawRef augments RawArrayView and RawArrayViewMut for power users needing unsafe element access (e.g. uninitialized buffers). Like LayoutRef, it is best used via AsRef / AsMut.