Skip to content

Conversation

@dependabot
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Oct 15, 2025

Updates the requirements on ndarray to permit the latest version.

Release notes

Sourced from ndarray's releases.

0.17.0

Version 0.17.0 (2025-10-14)

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.

When writing functions that accept array arguments:

  • Use &ArrayRef<A, D> to read elements from any array.
  • Use &mut ArrayRef<A, D> to modify elements.
  • Use &T where T: AsRef<LayoutRef<A, D>> to inspect shape/stride only.
  • Use &mut T where T: AsMut<LayoutRef<A, D>> to modify shape/stride only.

All existing function signatures continue to work; these new types are fully opt-in.

Background

ndarray has multiple ways to write functions that take arrays (a problem captured well in issue #1059). For example:

fn sum(a: ArrayView1<f64>) -> f64;
fn sum(a: &ArrayView1<f64>) -> f64;
fn sum(a: &Array1<f64>) -> f64;

All of these work, but having several equivalent forms causes confusion. The most general solution, writing generically over storage types:

fn sum<S>(a: &ArrayBase<S, Ix1>) -> f64
where S: Data<Elem = f64>;

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:

fn sum(a: &ArrayRef1<f64>) -> f64;
fn cumsum_mut(a: &mut ArrayRef1<f64>);

(ArrayRef1 is available from the prelude.)

Reading / Writing Shape: LayoutRef<A, D>

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>)
</tr></table> 

... (truncated)

Changelog

Sourced from ndarray's changelog.

Version 0.17.0 (2025-10-14)

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.

When writing functions that accept array arguments:

  • Use &ArrayRef<A, D> to read elements from any array.
  • Use &mut ArrayRef<A, D> to modify elements.
  • Use &T where T: AsRef<LayoutRef<A, D>> to inspect shape/stride only.
  • Use &mut T where T: AsMut<LayoutRef<A, D>> to modify shape/stride only.

All existing function signatures continue to work; these new types are fully opt-in.

Background

ndarray has multiple ways to write functions that take arrays (a problem captured well in issue #1059). For example:

fn sum(a: ArrayView1<f64>) -> f64;
fn sum(a: &ArrayView1<f64>) -> f64;
fn sum(a: &Array1<f64>) -> f64;

All of these work, but having several equivalent forms causes confusion. The most general solution, writing generically over storage types:

fn sum<S>(a: &ArrayBase<S, Ix1>) -> f64
where S: Data<Elem = f64>;

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:

fn sum(a: &ArrayRef1<f64>) -> f64;
fn cumsum_mut(a: &mut ArrayRef1<f64>);
</tr></table> 

... (truncated)

Commits

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Updates the requirements on [ndarray](https://github.com/rust-ndarray/ndarray) to permit the latest version.
- [Release notes](https://github.com/rust-ndarray/ndarray/releases)
- [Changelog](https://github.com/rust-ndarray/ndarray/blob/master/RELEASES.md)
- [Commits](rust-ndarray/ndarray@0.16.0...0.17.0)

---
updated-dependencies:
- dependency-name: ndarray
  dependency-version: 0.17.0
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot bot added dependencies Pull requests that update a dependency file rust Pull requests that update rust code labels Oct 15, 2025
@andrei-ng
Copy link
Collaborator

0.17.0 has been yanked. Closing this.

@andrei-ng andrei-ng closed this Oct 28, 2025
@dependabot @github
Copy link
Contributor Author

dependabot bot commented on behalf of github Oct 28, 2025

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

@dependabot dependabot bot deleted the dependabot/cargo/ndarray-0.17 branch October 28, 2025 18:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file rust Pull requests that update rust code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants