impl PartialEq<ErrorKind> for io::Error

[ChrisDenton]

This is an ergonomic improvement that allows directly testing io::Error against io::ErrorKind instead of needing to call kind(). Inspired by #93090.

r? @joshtriplett

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

Concerns:

• eq-to-wider-category (impl PartialEq<ErrorKind> for io::Error #93100 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[m-ou-se]

I'm not convinced it makes sense to consider an error and the wider category it falls into as 'equal'. This seems similar to adding PartialEq<FpCategory> for f64 to allow 1.0 == FpCategory::Normal.

Being able to skip .kind() doesn't seem that useful, and skipping that method call hides that an io::Error contains more information than just the io::ErrorKind.

(The PartialEq documentation even warns against "a comparison like the one above, which ignores some fields of the struct".)

@rfcbot concern eq-to-wider-category

[joshtriplett]

@m-ou-se True, but those additional fields (like the string) are for human consumption and printing, not typically for machine consumption. That seems like a notable difference.

[m-ou-se]

those additional fields (like the string) are for human consumption and printing, not typically for machine consumption.

That's not true for .raw_os_error() and also not for downcasting the dyn Error from .get_ref()/.into_inner().

[ChrisDenton]

Hm, the way I thought of it is that io::Error is an ErrorKind with the next error in the chain being either an OS error code or a dyn Error. Not sure if that's the right mental model though.

[m-ou-se]

Hm, the way I thought of it is that io::Error is an ErrorKind with the next error in the chain being either an OS error code or a dyn Error. Not sure if that's the right mental model though.

The wrapped error (whether an error code from the operating system or a custom dyn Error) is not used as the 'source' of the io::Error. The io::Error directly represents that error. .source() forwards to .source() on the dyn Error, not to the dyn Error itself:

rust/library/std/src/io/error.rs

Lines 800 to 807 in 84e9189

	fn source(&self) -> Option<&(dyn error::Error + 'static)> {
	match self.repr {
	Repr::Os(..) => None,
	Repr::Simple(..) => None,
	Repr::SimpleMessage(..) => None,
	Repr::Custom(ref c) => c.error.source(),
	}
	}

[joshtriplett]

those additional fields (like the string) are for human consumption and printing, not typically for machine consumption.

That's not true for .raw_os_error()

That's quite convincing, thank you.

This would be convenient, but I agree that it may not be the right solution. In particular, if we ever added a PartialEq between io::Error instances, err == some_kind might not match err == io::Error::from(some_kind).

[joshtriplett]

@rfcbot cancel

[rfcbot]

@joshtriplett proposal cancelled.

[ChrisDenton]

Yeah I'll close this now, thanks!

[joshtriplett]

@ChrisDenton Thank you for trying the experiment!