IMO durations should not be negative. The problem with having them define an infinite period is the following:
Lets say you want to compute the duration between two durations A and B: C = A-B; if A < B, C is negative and it will be infinite. I one want’s to check for the case mentioned in [1] about sleeping 0 marked with a negative duration, I think adding an explicit `if` is better since it reflects the intention. So in to conclude: 1. Duration operations should always be positive so A-B is effectively |A.underlying_type - B.underlying_type|. 2. We do need a constant or an specific trait to represent an infinite duration. > On 09 Mar 2016, at 17:20, Klaus Ma <[email protected]> wrote: > > One case I can image is to use negative value for forever duration? > > ---- > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer > Platform OpenSource Technology, STG, IBM GCG > +86-10-8245 4084 | [email protected] | http://k82.me > > On Wed, Mar 9, 2016 at 8:21 PM, Alex Rukletsov <[email protected]> wrote: > >> Folks, >> >> I've recently realized that durations we use in mesos (stout's `Duration` >> and `DurationInfo` protobuf) are based on signed integers. Negative >> duration concept is a bit strange to me, so I googled around a bit and >> found an interesting thread [1]. >> >> Was it an explicit intention to allow `Duration`s to be negative? Do we use >> this feature? If yes, maybe we can introduce a class representing time >> delta (can be negative) and base `Duration` on top of it guaranteeing it is >> always non-negative? >> >> My ultimate intention is to avoid boilerplate code that validates every >> single instance of `Duration` in the codebase. I'd rather have a class with >> guarantees certain invariants. >> >> [1] https://internals.rust-lang.org/t/unsigned-version-of-duration/893/2 >>
