Use IntoIterator
instead of Into<Vec<..>>
in cubic splines interfaces
#16402
+21
−21
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
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 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.