This crate contains the type GranularID, which is a data type which can provide ID numbers in
a sequential order, where between any two ID:s, there are infinitely many more granular ID:s.
You can think of this as version numbers with an infinite granularity, so if there are versions
1 and 2, there are ID:s 1.1, 1.2, 1.3 etc in-between them. Additionally, in-between ID 1.1 and
1.2, there are infinitely many ID:s 1.1.1, 1.1.2 and so on.
GranularIDs is best used with any unsized integer type, where each component of the ID:s may
range from the minimum bound to the maximum bound of that integer type. The GranularID that
starts with the upper bound of the integer type is the very maximum GranularID. This means
that, using u8, all these GranularID<u8>s exist, in increasing order:
254254.0254.1254.1.0254.1.1254.1.*- ...
254.2254.3255255is the highest ID available of this type (i.e. there is no255.0,255.1etc), and is the upper bound for this type. This constraint is added so that there is an upper bound to theGranularID<T>type ifThas an upper bound.
Even though it is recommended to use unsized integers for ID components, any types conforming
to the appropriate num_traits may
be used.
You may also think of the ID:s as a tree structure, where 3 has the children 3.0, 3.1 etc
up to 3.T::max, and 5.3 having the siblings 5.4, 5.5, 5.6 etc following it. For this
reason, [GranularId<T>::children], [GranularId<T>::next_siblings],
[GranularId<T>::previous_siblings] and [GranularId<T>::all_siblings], as well as
[GranularId<T>::parent] exist. If you were to build a tree structure, you may have a
root ID from which you assign all nodes living in the root ID:s from
the children of that root, and in turn assign each child of each children an ID derived from its
own ID. In that way, you are maintaining a total ordering of the children (assuming the
component type is totally ordered) while being able to easily find the parent ID of any node.
The root ID is a special ID since it doesn't have any components, and
is always the lowest ID.