You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can whip up a PR for this if it's considered a desired feature.
This would make it easier to write iterators that flatten matrices, where some or all of these matrices may be temporary objects that need to be moved into the iterator so as not to be referencing a temporary. For example:
// How it can be written currentlylet vertex_data = as.iter().zip(bs.iter()).flat_map(|(a, b)|
a.cross(&b).data.into_iter()).collect::<Vec<f32>>();// How it could be written afterwardlet vertex_data = as.iter().zip(bs.iter()).flat_map(|(a, b)|
a.cross(&b).into_iter()).collect::<Vec<f32>>();
I think this is a useful change, because having to dig into the matrix storage requires a deeper knowledge of the implementation details of Matrix, and is much less discoverable since there is no implementation of IntoIter for Matrix and solving it requires you to make the leap to the (hidden-by-default) data member to know that it does have an IntoIter implementation (which you can currently only find by going sideways through DefaultAllocator to ArrayStorage's Deref impl to GenericArray, manually googling it since the docs don't hyperlink types from external crates.)
Additionally, the current autoref to the IntoIter impl for &'a Matrix is unintuitive. If a user knows they have an owned MatrixMN, VectorN or PointN, it's intuitive that they should be able to convert it to an owned iterator, and it's confusing for it to borrow instead.
However, it would be a breaking change. The rust language itself is phasing in a similar breaking change where [T; N].into_iter() takes ownership of the array instead of auto-ref'ing to a slice iterator, so there is precedent for this.
The text was updated successfully, but these errors were encountered:
I got surprised by this behavior recently. I would favor making this change, and would also be willing to make the PR (though I'd need some pointers on how to proceed).
I can whip up a PR for this if it's considered a desired feature.
This would make it easier to write iterators that flatten matrices, where some or all of these matrices may be temporary objects that need to be moved into the iterator so as not to be referencing a temporary. For example:
I think this is a useful change, because having to dig into the matrix storage requires a deeper knowledge of the implementation details of
Matrix
, and is much less discoverable since there is no implementation ofIntoIter
forMatrix
and solving it requires you to make the leap to the (hidden-by-default)data
member to know that it does have anIntoIter
implementation (which you can currently only find by going sideways throughDefaultAllocator
toArrayStorage
'sDeref
impl toGenericArray
, manually googling it since the docs don't hyperlink types from external crates.)Additionally, the current autoref to the
IntoIter
impl for&'a Matrix
is unintuitive. If a user knows they have an ownedMatrixMN
,VectorN
orPointN
, it's intuitive that they should be able to convert it to an owned iterator, and it's confusing for it to borrow instead.However, it would be a breaking change. The rust language itself is phasing in a similar breaking change where
[T; N].into_iter()
takes ownership of the array instead of auto-ref'ing to a slice iterator, so there is precedent for this.The text was updated successfully, but these errors were encountered: