mirrors/arti.git/crates/tor-checkable/src/lib.rs, branch arti-v2.5.1 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.5.1 2026-07-23T10:13:34Z tor-checkable: TimeBound: Provide new build_intersect API 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-20T11:57:29Z urn:sha1:ddbd21c7d5f00702dd9e2071ef90383de59634a3 clippy config: Forbid TimeRangeBound::if_valid_now 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-20T16:55:48Z urn:sha1:9931210ab6943371401435a7a4bdcb091805caa5 tor-checkable: Rename `TimeBound::is_valid_at` to `check_valid_at` 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-20T16:51:12Z urn:sha1:b97c30a9e666d40601d76b645f44abc6adf42fe9 I find this names confusing. To my mind "is" implies a function returning `bool`. tor-checkable: Rename `TimeBound::check_valid_*` to `if_valid_*` 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-20T16:40:18Z urn:sha1:ca37f30a097696ce2ebd4e9945a4bdaebe086b31 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. tor-checkable: Deprecate `TimeBound::check_valid_at_opt` 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-20T16:37:49Z urn:sha1:008202a20b93dba7731462f82d1d01dbcc1b62d8 tor-checkable: TimeBound: Make wrapped type an associated type (fmt) 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-20T17:38:56Z urn:sha1:cc2b4debcd172debf2a043ea1146b3d4c652cc92 tor-checkable: TimeBound: Make wrapped type an associated type 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-20T12:00:15Z urn:sha1:b16e7a5ac48daa3e2f94660bdf7c39f54e7c702c It wouldn't make much sense for one concrete type to be unwrappable variously as different inner types. tor-checkable: TimeBound: Make is_valid_at a provided method 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-16T15:30:15Z urn:sha1:9313f79335c2ba15e7e60bc6d97086c4c56ff30a 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. tor-checkable: TimeBound: remove Error associated type 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-16T15:19:05Z urn:sha1:726f97b2a2099eea34d804e0132cf742964af8b7 This was always TimeValidityError. And we want to rely on that so we can do the validity checking more centrally. tor-checkable: TimeBound: Add bounds accessor 2026-07-23T10:13:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-07-20T18:25:52Z urn:sha1:845f56aeedabfd44ec4573f872aeefa77cf72556 This makes a `TimeBound` much more convenient to work with, will allow more centralisation. This replaces temporary `bound` inherent method on `TimeRangeBound`.