Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep Vec::capacity const #498

Merged
merged 1 commit into from
Jul 2, 2024

Conversation

sosthene-nitrokey
Copy link
Contributor

@sosthene-nitrokey sosthene-nitrokey commented Jul 2, 2024

In 0.8.0 it was const, but this was removed in #486, which would be an unexpected breaking change.

The other container types did not make the capacity method const, and therefore can kept with the normal name and the generic implementation.

No need for changelog for this change, since it affects b previous PR that has not been released.

In 0.8.0 it was const, but this was removed in rust-embedded#486

The other container types did not make the `capacity` method const, and therefore can kept with the normal name and the generic implementation.
@sosthene-nitrokey sosthene-nitrokey force-pushed the breaking-change-vec-capacity branch from 94b0ea5 to 27bff4a Compare July 2, 2024 15:20
Copy link
Member

@Dirbaio Dirbaio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh oops, nice find! thanks

@Dirbaio Dirbaio added this pull request to the merge queue Jul 2, 2024
Merged via the queue into rust-embedded:main with commit 1c47ffc Jul 2, 2024
22 checks passed
@@ -408,7 +415,7 @@ impl<T, S: Storage> VecInner<T, S> {
}

/// Returns the maximum number of elements the vector can hold.
pub fn capacity(&self) -> usize {
pub fn storage_capacity(&self) -> usize {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sosthene-nitrokey, why can't this use the same name?

Copy link
Member

@Dirbaio Dirbaio Jul 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

storage_capacity applies to VecInner<T, S>, for any storage
capacity applies to VecInner<T, OwnedStorage<N>> aka Vec<T, N> only.

so for Vec<T, N> both apply, so it'd give ambiguity errors if the user wrote vec.capacity()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so for Vec<T, N> both apply, so it'd give ambiguity errors if the user wrote vec.capacity()

It wouldn't even allow getting to that point. The compiler would complain about duplicate definitions with the same name.

We could implement fn capacity on Vec and VecView independently, but then it would make it unusable in a generic context over the storage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants