Skip to content

List of breaking changes for next breaking release #217

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

Open
8 tasks
fitzgen opened this issue Apr 8, 2025 · 6 comments
Open
8 tasks

List of breaking changes for next breaking release #217

fitzgen opened this issue Apr 8, 2025 · 6 comments

Comments

@fitzgen
Copy link
Member

fitzgen commented Apr 8, 2025

Anything else?

@kpreid
Copy link
Contributor

kpreid commented Apr 8, 2025

I was just working on improving some Arbitrary implementations, and I think un-splitting try_size_hint would be very much worthwhile to reduce the number of possible mistakes.

Other suggestions:

  • Consider a custom type for easier size hints #201 — add a SizeHint struct to make it much less verbose to construct size hints, since they could be combined using + and | operators (instead of methods).
  • Consider flipping the definition of depth so that instead of accepting the current depth with a hard-coded MAX_DEPTH, the parameter is itself a maximum further depth, and recursion decrements rather than increments it. That way, if an application finds itself hitting a depth limit it can just ask for more depth instead of having to modify the library.

@kpreid
Copy link
Contributor

kpreid commented Apr 9, 2025

P.S. I'd be happy to try writing a PR for the SizeHint breaking change if there is interest.

@fitzgen
Copy link
Member Author

fitzgen commented Apr 9, 2025

Consider a custom type for easier size hints #201 — add a SizeHint struct to make it much less verbose to construct size hints, since they could be combined using + and | operators (instead of methods).

Sounds good to me. I'm fine with the operator overloading sugar, but I think there should still be named methods that the operators just forward to for better rust docs discoverability.

Consider flipping the definition of depth so that instead of accepting the current depth with a hard-coded MAX_DEPTH, the parameter is itself a maximum further depth, and recursion decrements rather than increments it. That way, if an application finds itself hitting a depth limit it can just ask for more depth instead of having to modify the library.

Also sounds good to me 👍

P.S. I'd be happy to try writing a PR for the SizeHint breaking change if there is interest.

For just the types or the trait methods as well? Either way, that would be very welcome!

@fitzgen
Copy link
Member Author

fitzgen commented Apr 9, 2025

#191 wouldn't be a breaking change, but is another pet issue I have but haven't gotten around to implementing. If we are doing a breaking change, that probably involves some amount of outwards communication, and having this as a cool new feature to help motivate upgrades would be nice to bundle in as well.

@fitzgen
Copy link
Member Author

fitzgen commented Apr 9, 2025

A note I got from an arbitrary user in private chat: support regular a..b ranges (instead of only a..=b ranges) in Unstructured::int_in_range.

Note that we can't only have a..b ranges, or else you wouldn't be able to express including the int's max value in the range, but with some trait sugar we should be able to support both in the same method.

@kpreid
Copy link
Contributor

kpreid commented Apr 10, 2025

PR #218 adds the SizeHint type and combines try_size_hint() into size_hint(). (It does not change the meaning of the depth parameter.)

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

No branches or pull requests

2 participants