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

replace all FnMut with FnOnce in put_reserve_* #251

Merged
merged 1 commit into from
Apr 29, 2024

Conversation

nolanderc
Copy link
Contributor

Pull Request

Related issue

N/A

What does this PR do?

  • Replaces FnMut with FnOnce in all put_reserve_* functions.
    • A value should only be written once, so FnMut is needlessly restrictive; with FnOnce we allow more functions to be used.

PR checklist

Please check if your PR fulfills the following requirements:

  • Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
  • Have you read the contributing guidelines?
  • Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Copy link
Member

@Kerollmops Kerollmops left a comment

Choose a reason for hiding this comment

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

Thank you very much 👌

@Kerollmops Kerollmops merged commit 7e2e105 into meilisearch:main Apr 29, 2024
8 checks passed
@Kerollmops Kerollmops modified the milestones: v0.21.0, v0.20.1 Apr 29, 2024
@Kerollmops
Copy link
Member

I am wondering if this is a breaking change 🤔 Because it is not constraining more....

@nolanderc
Copy link
Contributor Author

I am wondering if this is a breaking change 🤔 Because it is not constraining more....

It shouldn't be: any code which previously passed a FnMut closure will still compile as all FnMut closures also implement FnOnce.

Granted, this is a signature change, so if somebody passed the function pointer to another function foo(Database::put_reserved), where foo had an FnMut bound on the write_value parameter, this would no longer compile. So technically this is breaking, but I can’t think of why you would do something like that…

@Kerollmops
Copy link
Member

Ok, so we can call that a soft-breaking change, and therefore, it's allowed 🤭 Thank you. It will be released in v0.20.1, then.

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

Successfully merging this pull request may close these issues.

None yet

2 participants