-
Notifications
You must be signed in to change notification settings - Fork 18
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
Support custom panic messages and add assert_eq!
#224
Conversation
f26cbb0
to
b31c150
Compare
assert_eq!
.assert_eq!
|
||
/// A [`std::assert_eq`] compatible wrapper around the [`Assert`] API. | ||
#[macro_export] | ||
macro_rules! assert_eq { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would make sense to also add respective macros for assert_matches
and assert_eq_path
and assert_matches_path
... however I really dislike the names of the latter two, see #225. So I'd rather have us do a breaking rename before adding the new same-named macros.
|
The |
Yes, I had overlooked that. However, that should have a full "BREAKING CHANGES" section because the subject does not describe the breaking change. |
Yeah that makes sense. I do have to note that I find your tendency to eagerly close PRs somewhat off-putting. You could just convert it to a draft. |
If you are wanting to demonstrate something, you are free to create a branch and link to it or to create a draft yourself. It is too easy for conversations to live too long in PRs that should instead be in Issues. There is also a social pressure to merge PRs, putting an undo burden on maintainers. Some maintainers take the approach of not caring about their users. Others try to bend over backwards for them and burn out. I'm trying to walk a middle ground. Pushing conversations to Issues by closing PRs is one of the boundaries I maintain. |
Thanks for elaborating. From your comment in #223:
If you'd said that here, I'd have just converted the PR to a draft to signal that it's not ready and then either closed it or force pushed an alternative design that addresses your concerns. I guess I have less of an issue with you closing PRs to move the discussion to issues and more of an issue with what you said before closing this issue:
Aside from the fact that PR descriptions can easily be updated, starting the first reply to a PR with "This is a breaking change" just does not feel very appreciative or welcoming. |
Yes, maybe I could have better worded things. I'd also recommend looking at this from a maintainer's perspective in the boldness of a PR being the first time the subject of a breaking change is broached combined with it never being explained and justified which should be front and center in the PR description. |
Resolves #223.