Implement more traits for `std::io::ErrorKind` #35911

Merged
merged 2 commits into from Sep 1, 2016

Conversation

Projects
None yet
9 participants
@tbu-
Contributor

tbu- commented Aug 23, 2016

This makes it possible to use it as key in various maps.

Implement more traits for `std::io::ErrorKind`
This makes it possible to use it as key in various maps.
@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Aug 23, 2016

Collaborator

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

Collaborator

rust-highfive commented Aug 23, 2016

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton alexcrichton added the T-libs label Aug 23, 2016

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 23, 2016

Member

Could you expand on the motivation of being able to use in various maps as well? One specific aspect here was to reorder the enum, and it seems like we would want to provide zero guarantees about the ordering of this enum.

Member

alexcrichton commented Aug 23, 2016

Could you expand on the motivation of being able to use in various maps as well? One specific aspect here was to reorder the enum, and it seems like we would want to provide zero guarantees about the ordering of this enum.

@tbu-

This comment has been minimized.

Show comment
Hide comment
@tbu-

tbu- Aug 23, 2016

Contributor

I write a tool that operates on a large number of files, and it tries to display an error summary at the end. Currently, I have an almost-exact mirror of the ErrorKind enum in the code in order to be able to put it into a HashMap.

Do we guarantee that the ordering stays the same for types that derive ordering? I don't think that's all too useful, because we also don't want to guarantee the ordering for other enums where you can obtain it by casting it to an integer (e1 as u32 < e2 as u32). Maybe we need to have some kind of discussion about that.

Contributor

tbu- commented Aug 23, 2016

I write a tool that operates on a large number of files, and it tries to display an error summary at the end. Currently, I have an almost-exact mirror of the ErrorKind enum in the code in order to be able to put it into a HashMap.

Do we guarantee that the ordering stays the same for types that derive ordering? I don't think that's all too useful, because we also don't want to guarantee the ordering for other enums where you can obtain it by casting it to an integer (e1 as u32 < e2 as u32). Maybe we need to have some kind of discussion about that.

@Stebalien

This comment has been minimized.

Show comment
Hide comment
@Stebalien

Stebalien Aug 23, 2016

Contributor

(IMO, these methods should all panic when called on __NonExhaustive as a sanity check but that's probably not too important given that it's unstable).

Contributor

Stebalien commented Aug 23, 2016

(IMO, these methods should all panic when called on __NonExhaustive as a sanity check but that's probably not too important given that it's unstable).

@ollie27

This comment has been minimized.

Show comment
Hide comment
@ollie27

ollie27 Aug 23, 2016

Contributor

If we're not supposed to have any guarantees about the ordering of this enum then it probably shouldn't be a C-Like enum. We're currently exposing an ordering: assert!((ErrorKind::Other as isize) < (ErrorKind::UnexpectedEof as isize)).

Contributor

ollie27 commented Aug 23, 2016

If we're not supposed to have any guarantees about the ordering of this enum then it probably shouldn't be a C-Like enum. We're currently exposing an ordering: assert!((ErrorKind::Other as isize) < (ErrorKind::UnexpectedEof as isize)).

@Stebalien

This comment has been minimized.

Show comment
Hide comment
@Stebalien

Stebalien Aug 23, 2016

Contributor

@ollie27 (that also means that this change cannot reorder fields without being a breaking change).

Contributor

Stebalien commented Aug 23, 2016

@ollie27 (that also means that this change cannot reorder fields without being a breaking change).

@tbu-

This comment has been minimized.

Show comment
Hide comment
@tbu-

tbu- Aug 24, 2016

Contributor

@Stebalien I don't think we consider that a breaking change, see e.g. #25246 or rust-lang/rfcs#906. It doesn't realistically break any code.

Contributor

tbu- commented Aug 24, 2016

@Stebalien I don't think we consider that a breaking change, see e.g. #25246 or rust-lang/rfcs#906. It doesn't realistically break any code.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Aug 24, 2016

Member

I don't really see why we'd want to reorder these variants?

Member

sfackler commented Aug 24, 2016

I don't really see why we'd want to reorder these variants?

@tbu-

This comment has been minimized.

Show comment
Hide comment
@tbu-

tbu- Aug 24, 2016

Contributor

Just for consistency I guess, but I can remove that part. I thought Other at the end made the most sense and it was the case until UnexpectedEof was added.

Contributor

tbu- commented Aug 24, 2016

Just for consistency I guess, but I can remove that part. I thought Other at the end made the most sense and it was the case until UnexpectedEof was added.

@tbu-

This comment has been minimized.

Show comment
Hide comment
@tbu-

tbu- Aug 24, 2016

Contributor

To clarify, this was ment as a drive-by fix, not part of the whole pull request. I restored the old ordering because apparantly this is not a tiny change.

Contributor

tbu- commented Aug 24, 2016

To clarify, this was ment as a drive-by fix, not part of the whole pull request. I restored the old ordering because apparantly this is not a tiny change.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
Member

alexcrichton commented Aug 29, 2016

@bors: r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 29, 2016

Contributor

📌 Commit c2d064e has been approved by alexcrichton

Contributor

bors commented Aug 29, 2016

📌 Commit c2d064e has been approved by alexcrichton

@jonathandturner

This comment has been minimized.

Show comment
Hide comment
@jonathandturner

jonathandturner Aug 31, 2016

Contributor

@bors rollup

Contributor

jonathandturner commented Aug 31, 2016

@bors rollup

jonathandturner added a commit to jonathandturner/rust that referenced this pull request Aug 31, 2016

Rollup merge of #35911 - tbu-:pr_io_errorkind_traits, r=alexcrichton
Implement more traits for `std::io::ErrorKind`

This makes it possible to use it as key in various maps.

bors added a commit that referenced this pull request Sep 1, 2016

@bors bors merged commit c2d064e into rust-lang:master Sep 1, 2016

@bluss bluss added the relnotes label Sep 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment