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

Breaking changes for v2.0 #39

Open
5 tasks
cljoly opened this issue Feb 27, 2023 · 4 comments
Open
5 tasks

Breaking changes for v2.0 #39

cljoly opened this issue Feb 27, 2023 · 4 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@cljoly
Copy link
Owner

cljoly commented Feb 27, 2023

A wishlist of breaking changes for the next major version:

  • Change return types so that we can fix the cargo clippy pedantic warnings, like casting `i64` to `usize` may lose the sign of the value or casting `usize` to `u32` may truncate the value on targets with 64-bit wide pointers
  • Introduce intermediary types so that we could write M::up(…).hook(…).down(…).hook(…)
  • Remove deprecated items

Other things to decide on:

I don’t know if a breaking version will ever be released though, there are costs to forcing users to migrate.

Repository owner locked and limited conversation to collaborators Feb 27, 2023
@cljoly cljoly added documentation Improvements or additions to documentation enhancement New feature or request labels Feb 27, 2023
@czocher
Copy link
Collaborator

czocher commented Jun 17, 2023

We can probably also remove PartialEq from our Error implementation.

Maybe also migrate to thiserror?

@cljoly
Copy link
Owner Author

cljoly commented Jun 18, 2023

We can probably also remove PartialEq from our Error implementation.

That’s a good point, I’ve added it to the checklist at the top.

Maybe also migrate to thiserror?

What prevents us from doing it? We could do it in a way that doesn’t break the API compatibility, couldn’t we?

@czocher
Copy link
Collaborator

czocher commented Jun 18, 2023

What prevents us from doing it? We could do it in a way that doesn’t break the API compatibility, couldn’t we?

I believe so, we can create a task for that if we deem it worthwhile.

@cljoly
Copy link
Owner Author

cljoly commented Jun 18, 2023

I’ve created #95 for this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants