Implement `Default` for `std::time::Duration`

[luser]

Duration doesn't implement Default. I found this out because I had a struct with #[derive(Default)] and I tried to add a Duration member to it, and that no longer worked. This means that I'd have to manually implement Default, which stinks because the struct has quite a few members. It seems like we could give Duration an implementation that just returns a zero-length Duration.

[vaartis]

This seems quite simple for a beginner, if everybody's ok with it, may i do it?

[alexcrichton]

This was originally proposed in #32785 where when the libs team discussed it concluded that there's not a "clearly correct" default value for the Duration type.

That being said I'd personally be ok with just returning a zero duration, so I'd be curious if others from @rust-lang/libs could weigh in on this.

[sfackler]

The zero duration seems as reasonable as a default as 0 does for integer types, so I'd be on board with this. If nothing else, given a Default impl for Duration, it's the only value that could possibly make sense.

[luser]

I guess I can see that argument, like if you had:

struct SomeOptions {
  things: usize,
  timeout: Duration,
}

You probably wouldn't want to have timeout default to zero if you used #[derive(Default)]. However, I have a hard time believing that #[derive(Default)] would be the right choice for an options struct like that in the first place.

For APIs that take a timeout parameter, I suppose you could have an odd situation where people pass Default::default() or Duration::default(), but you could already have that with any parameter that implements Default, and I can't say I've come across it in practice. It seems more likely that an API would use Option<Duration> for such a thing, or a hand-written Default implementation.

[aturon]

I agree that if we have a default, 0 is the only sensible one to choose. It just continues to make me nervous that I can't think of many situations where that's actually the default you want for a duration -- but in any case where a default even makes sense, you should be using Option<Duration>.

@luser Out of curiosity, how is the duration being used in the struct that led you to this problem? And is 0 really the "right" default for your case?

[luser]

@aturon I wanted to use it to accumulate a running duration of a set of events in a struct that accumulates stats:
https://github.com/luser/sccache2/blob/a7b5349da1d54ddba72f0640b0d388f0b9d61c00/src/server.rs#L121

Each event returns a Duration so I thought it'd be easy to just store one and accumulate it, but I didn't feel like writing the Default implementation by hand there, so I punted:
https://github.com/luser/sccache2/blob/a7b5349da1d54ddba72f0640b0d388f0b9d61c00/src/server.rs#L719

[aturon]

@luser Thanks, makes perfect sense!

TLDR: a good reason for a default duration is accumulation, and zero is the right starting point. And I can't really see any way in which this is a footgun (as we all keep saying, zero's the only value that could make sense anyway). So 👍.

However, given that there was some contention about this before, I'm going to run this change by the full libs team for approval:

@rfcbot fcp merge

[aturon]

@Tyannn Once the team has agreed we want to make this change, we'd be happy to take a PR from you implementing it!

[rfcbot]

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

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @brson
• @sfackler

No concerns currently listed.

Once these reviewers reach consensus, 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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @aturon, I wasn't able to add the final-comment-period label, please do so.