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

misc: Make error enums unconditionally non_exhaustive #652

Merged
merged 4 commits into from Jul 2, 2021

Conversation

DevinR528
Copy link
Member

No description provided.

crates/ruma-serde/src/canonical_json.rs Outdated Show resolved Hide resolved
@@ -52,6 +52,7 @@ impl<'input, 'output, Target: UrlEncodedTarget> Serializer<'input, 'output, Targ

/// Errors returned during serializing to `application/x-www-form-urlencoded`.
#[derive(Clone, Debug, PartialEq, Eq)]
#[non_exhaustive]
pub enum Error {
Copy link
Member

Choose a reason for hiding this comment

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

I kinda dislike this being an enum at all, but that's something that can be refactored separately.

Copy link
Member Author

Choose a reason for hiding this comment

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

What were you thinking?

Comment on lines 16 to 17
#[allow(clippy::exhaustive_enums)]
pub enum EventFormatVersion {
Copy link
Member

Choose a reason for hiding this comment

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

Why not make this one non-exhaustive?

Copy link
Member Author

Choose a reason for hiding this comment

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

So I wasn't sure about this or below but my idea was there this would always be a breaking change in the spec, and that it might be better to have an obvious break from version to version 🤷

Copy link
Member

Choose a reason for hiding this comment

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

The whole purpose of room versions is being able to change things without breaking existing code. Why would adding to this inherently be a breaking change?

Copy link
Member Author

Choose a reason for hiding this comment

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

Would the spec not semver bump? I guess I'm not sure about ruma's semver guarantees with respect to the matrix spec changes and their versioning? This probably kinda relates to my question about non_exhaustive enums with a _Custom variant and forward compat? If I had a better idea of how/when we want to make breaking changes.

Comment on lines 27 to 28
#[allow(clippy::exhaustive_enums)]
pub enum StateResolutionVersion {
Copy link
Member

Choose a reason for hiding this comment

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

Same question here.

@DevinR528
Copy link
Member Author

I made both of the state-res RoomVersion structs non_exhaustive so I think this PR is ready unless you want me to mess with the enum urlencode::ser::Error?

@jplatte jplatte merged commit 94ddfc2 into ruma:main Jul 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants