To remove redundancy in setting up unit tests for each concrete Interval type (e.g. IntInterval implementing Interval<Int, UInt>), BasicTypeIntervalsTest.kt uses an inline function to retrieve the type operations for the type parameters (using getBasicTypeOperationsFor()).

This manually needs to be kept in sync if the operations ever change.

Is there a way to directly retrieve the matching TypeOperations from the concrete types? Maybe through a common factory interface on the companion objects?

With the addition of TSize as a type parameter for Interval, overflows for almost all types are prevented by relying on TSize operations to prevent T values from overflowing.

However, as commented when closing this issue:

DoubleInterval can still overflow since there is no suitable type that can be specified to cover Double.MAX_VALUE - Double.MIN_VALUE. This is probably okay as an edge case, but this should probably throw an exception when accessing size rather than it being ignored.

Currently, the IntervalTest.size_can_be_greater_than_max_value for DoubleIntervalTest succeeds since Double.Infinity is returned for both the expected and calculated value. This should not succeed for Double and probably give a runtime exception instead.

Types with negative numbers can represent a - larger interval size than can be represented by the type itself

Once generic size parameters are introduced for intervals (#1), this can likely be fixed by using the unsigned matching type as the size parameter.

DateTime intervals will need this, since the size between two dates is not a date itself.

Similarly, the size between two chars is probably better expressed as a byte

An initial contract definition for IntervalUnion and preliminary concrete MutableIntervalUnion which lives up to the contract by restricting which intervals can be added.

To help verify the IntervalUnion contract, I included the Interval.intersects(), Interval.reverse(), and Interval.nonReversed() methods.

A common operation is to reverse intervals: swapping start and isStartIncluded with end and isEndIncluded.

Currently, I added an inner fun to assertIntersects in IntervalTest as part of ongoing IntervalUnion work. #22

Common operations on intervals are to:

• add/remove a value or interval
• get complementary interval

These may result not in a single interval, but in what can be called an interval union. This can be stored as a sorted list of non-overlapping intervals. Operations which may result in interval unions should return IntervalUnion, others can continue to return a normal Interval.

Closes #12

Turned the main kotlinx.interval into a submodule as part of a multi-module project.

To be able to reuse the test base classes from other modules, I moved them to a new submodule kotlinx.interval.test. Rather than pulling in this dependency in each kotlinx.interval library, a test dependency to this library should likely be included as part of the interval.library-conventions gradle plugin (#14).

Next up is adding kotlinx.interval.datetime which defines Interval<Instant, Duration>.

Include Interval<Instant, Duration>.

Since this depends on the kotlinx datetime library, implement it as a separate module: kotlinx.interval.datetime.

A first functional, but still unstable, version.

Open/closed intervals with generic T and TSize and size property. Default intervals are included for all basic Kotlin types, e.g. IntInterval, DoubleInterval, etc.

If these implementations can be assumed tested in separate unit tests, they can probably be used to simplify the implementation of IntervalTest.

E.g. use subtract to calculate a size, rather than passing it, and zero could be included in TypeOperators.

end does not always need to lie after start. When start lies after end, an interval is called "reversed".

When operating and comparing intervals, however, it is useful to normalize them. Part of this is to make sure start always lies before end.

Can isStartInlcuded and isEndIncluded also be normalized for discrete types? E.g. for integers ]0, 1] can be normalized to [1, 1].

Currently, I added an inner normalize function to intersects solely dealing with start/end reversal as part of ongoing IntervalUnion work: #22

With the introduction of kotlinx-interval-datetime as a submodule, buildSrc is used to apply a conventions plugin.

But, this can be cleaned up a bit:

• [ ] Central definition of versions. It is spread out between buildSrc/build.gradle.kts and build.gradle.kts at the moment, since the Nexus Gradle Plugin has to be applied to the main project.
• [ ] Double loading of publish.properties in buildSrc/build.gradle.kts and the interval.library-conventions.gradle.kts plugin.
• [ ] Add a test dependency on kotlinx.interval.test. But, this will require kotlinx.interval.test not to apply the convention plugin itself, perhaps only a subset defined in a new separate convention plugin.