The type IntoIter implemented in #986 is not exposed publicly, which makes it difficult or impossible to implement IntoIterator trait for custom types wrapping ndarray:
use ndarray::iterators::IntoIter; // Module `iterators` is private
pub struct Foo {
array: Array1<i32>,
}
impl IntoIterator for Foo {
type Item = i32;
type IntoIter = IntoIter<i32, Ix1>; // `IntoIter` is private
fn into_iter(self) -> Self::IntoIter {
self.array.into_iter()
}
}
The type is private in it's own module, re-exported publicly from module iterators, however module iterators itself is not public in lib.rs:
The sibling types Iter and IterMut are exposed additionally in lib.rs
|
use crate::iterators::{ElementsBase, ElementsBaseMut, Iter, IterMut}; |
I believe that the reason why the author of the PR missed this is the unnecessary spaghetti of re-exports. There seem to be no particular pattern in place. Why is this complexity needed? How it can be improved?
Proposed changes:
- expose
IntoIter publicly to solve this problem directly
- refactor public exports to avoid unnecessary complexity and prevent this kind of bugs from happening again
- add tests validating public interface of the library; require these tests to be added along with the new functionality in PRs affecting public interface
The type
IntoIterimplemented in #986 is not exposed publicly, which makes it difficult or impossible to implementIntoIteratortrait for custom types wrappingndarray:The type is private in it's own module, re-exported publicly from module
iterators, however moduleiteratorsitself is not public inlib.rs:ndarray/src/lib.rs
Line 191 in 97ecc0d
The sibling types
IterandIterMutare exposed additionally inlib.rsndarray/src/lib.rs
Line 146 in 97ecc0d
I believe that the reason why the author of the PR missed this is the unnecessary spaghetti of re-exports. There seem to be no particular pattern in place. Why is this complexity needed? How it can be improved?
Proposed changes:
IntoIterpublicly to solve this problem directly