Implement Default for more types in the standard library
#32785
Conversation
|
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
|
There was a reddit comment that motivated this (especially for |
|
The added other trait impls also should be mentioned in the commit message or PR. |
|
@bluss Updated. |
|
Thanks @tbu-! Tagging with |
alexcrichton
added
the
T-libs-api
| #[stable(feature = "duration_default", since = "1.9.0")] | ||
| impl Default for Duration { | ||
| fn default() -> Duration { | ||
| Duration::new(0, 0) |
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.
|
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. |
|
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. |
|
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! |
|
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`.
|
I also see no problem with |
Implement `Default` for more types in the standard library Also add `Hash` to `std::cmp::Ordering` and most possible traits to `fmt::Error`.
|
@tbu- 👍 |
|
This fixes #31865. |
|
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.