Uh oh!
There was an error while loading. Please reload this page.
Implement Default for more types in the standard library - #32785
Conversation
rust-highfive
commented
Apr 7, 2016
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
tbu-
commented
Apr 7, 2016
There was a reddit comment that motivated this (especially for |
bluss
commented
Apr 7, 2016
The added other trait impls also should be mentioned in the commit message or PR. |
tbu-
commented
Apr 7, 2016
@bluss Updated. |
alexcrichton
commented
Apr 7, 2016
Thanks @tbu-! Tagging with |
There was a problem hiding this comment.
My question on StackOverflow has brought up the concern that a 0-duration is not a sensible default in most cases. Using this e.g. as a timeout is bound to fail at runtime. It's probably better not to implement Default for Duration at all.
There was a problem hiding this comment.
Why would it fail at runtime? The drawbacks were not fully explained on SO.
There was a problem hiding this comment.
The problem is that Durations are often used as Timeouts and unless zero-duration timeouts are special case, the operation will always time out by default.
There was a problem hiding this comment.
I don't have strong feelings about this, we can definitely remove this if this isn't wanted. Two upsides: Using 0 seems to have some precedence (integers, floats), even though it's not clear where you'll use them. Implementing Default for more types means that you can #[derive] it in more cases.
There was a problem hiding this comment.
Yeah, that was exactly the argument I made in the reddit comment. And of course the default just has to make intuitive sense; we cannot foresee possible applications. Still, I'd like to have more input for this before we commit to an implementation, especially as insta-stability means we cannot easily back off.
llogiq
commented
Apr 8, 2016
That reddit comment was by me. This would fix #31865 (and some more) by the way. I'm also unsure if this should be directly stable. |
llogiq
commented
Apr 8, 2016
OK, so TIL trait impls are insta-stable. 😄 Apart from being unsure about the 'correct' default value for Duration (zero seems to make intuitive sense for timestamp arithmetic, but is a bad choice for timeouts), I'm in favor of this. It's more complete than #32807. |
alexcrichton
commented
Apr 15, 2016
The libs team discussed this during triage yesterday and the decision was that most of these seem fine but we should avoid doing something just for the sake of doing something. In line with that the default impls for Other than that though this looked good to us! |
tbu-
commented
Apr 15, 2016
The use case I have in mind here is when you have a |
Also add `Hash` to `std::cmp::Ordering` and most possible traits to `fmt::Error`.
llogiq
commented
Apr 15, 2016
I also see no problem with |
alexcrichton
commented
Apr 15, 2016
bors
commented
Apr 16, 2016
Implement `Default` for more types in the standard library Also add `Hash` to `std::cmp::Ordering` and most possible traits to `fmt::Error`.
bors
commented
Apr 16, 2016
llogiq
commented
Apr 16, 2016
@tbu- 👍 |
llogiq
commented
Apr 16, 2016
This fixes #31865. |
bombless
commented
Apr 26, 2016
I cannot think of a more proper default value for IMO if your scenario has a more proper value for a duration it should be a separate type and you may want to express duration itself through a trait. And the implementation of |
Also add
Hashtostd::cmp::Orderingand most possible traits tofmt::Error.