The type IntoIter implemented in https://github.com/rust-ndarray/ndarray/pull/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()
}
}
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
IntoIter
implemented in https://github.com/rust-ndarray/ndarray/pull/986 is not exposed publicly, which makes it difficult or impossible to implementIntoIterator
trait for custom types wrappingndarray
:The type is private in it's own module, re-exported publicly from module
iterators
, however moduleiterators
itself is not public inlib.rs
: https://github.com/rust-ndarray/ndarray/blob/97ecc0db70d53a1119c7b03149fcd7207d4580bd/src/lib.rs#L191The sibling types
Iter
andIterMut
are exposed additionally inlib.rs
https://github.com/rust-ndarray/ndarray/blob/97ecc0db70d53a1119c7b03149fcd7207d4580bd/src/lib.rs#L146I 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:
IntoIter
publicly to solve this problem directly