This was always a bit weird; IntoIterator is considered more idiomatic in Rust.
The reason these used Into<Vec<..>> in the first place was (to my knowledge) because of concerns that passing an already-owned vector would cause a redundant allocation if the iterator API was used instead. However, I have looked at simple examples for this scenario and the generated assembly is identical (i.e. into_iter().collect() is effectively converted to a no-op).
Solution
As described in the title.
Testing
It compiles. Ran existing tests.
Migration Guide
The cubic splines API now uses IntoIterator in places where it used Into<Vec<..>>. For most users, this will have little to no effect (it is largely more permissive). However, in case you were using some unusual input type that implements Into<Vec<..>> without implementing IntoIterator, you can migrate by converting the input to a Vec<..> before passing it into the interface.
Objective
This was always a bit weird;
IntoIteratoris considered more idiomatic in Rust.The reason these used
Into<Vec<..>>in the first place was (to my knowledge) because of concerns that passing an already-owned vector would cause a redundant allocation if the iterator API was used instead. However, I have looked at simple examples for this scenario and the generated assembly is identical (i.e.into_iter().collect()is effectively converted to a no-op).Solution
As described in the title.
Testing
It compiles. Ran existing tests.
Migration Guide
The cubic splines API now uses
IntoIteratorin places where it usedInto<Vec<..>>. For most users, this will have little to no effect (it is largely more permissive). However, in case you were using some unusual input type that implementsInto<Vec<..>>without implementingIntoIterator, you can migrate by converting the input to aVec<..>before passing it into the interface.