| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4223#note_3438344
|
| | |
|
| |
|
|
|
| |
I find this names confusing. To my mind "is" implies a function
returning `bool`.
|
| |
|
|
|
|
|
| |
I find these names confusing. To my mind "check" implies a function
returning `Result<(), _>`.
Some other APIs use `unwrap` here but I think `if` is good.
|
| | |
|
| |
|
|
|
| |
It wouldn't make much sense for one concrete type to be unwrappable
variously as different inner types.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that we have `bounds()`, we can centralise this implementation and
delete the implementations.
I don't think it's necessary to provide an engineered safeguard
against downstreams overriding this method. Any existing implementors
of this trait will break because they must provide `.bounds()` now,
which is an opportunity to notice that the `is_valid_at` can be
deleted. But, if it is not deleted, nothing goes wrong.
|
| |
|
|
|
| |
This was always TimeValidityError. And we want to rely on that so we
can do the validity checking more centrally.
|
| |
|
|
|
|
|
| |
This makes a `TimeBound` much more convenient to work with, will allow
more centralisation.
This replaces temporary `bound` inherent method on `TimeRangeBound`.
|
| | |
|
| |
|
|
|
| |
This is our time range type, so it wants a bunch of useful methods and
conversions.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It was confusing that one of these functions had "which bound"
mentioned in its name, but the other didn't. So add `end` and switch
from `tolerance` to `bound` (see previous commit message).
*This* commit should deal only in `extend_tolerance` and `end` and
shouldn't touch `extend_start_bound` or `extend_pre_tolerance`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although it is often used to apply a tolerance, it doesn't make sense
to say that this is extending the "tolerance" of a `TimeRangeBound`.
A `TimeRangeBound` doesn't have a tolerance, only bounds.
Also we should be consistent in our terminology, and use `start`
rather than `pre`.
We'll rename the other method too. Doing them one at a time will
makes it easier to spot any "pre/start" vs "<nothing>/end" slips:
*this* commit should deal only in `pre` and `start` and shouldn't
touch `extend_tolerance`.
|
| |
|
|
|
|
| |
This module has only few public items - currently, only one. And it
has the word "time" in it. It doesn't make sense to expect callers to
write `timed::`.
|
| |
|
|
| |
For consistency with the TimeBound trait.
|
| |
|
|
| |
For consistency with TimeRangeBounds (currently TimerangeBounds).
|
| | |
|
| |
|
|
| |
Fixes: #1691
|
| | |
|
|
|
I want one of these for the bridge descriptor downloader, and they
seem reasonable to me.
|
