Why use multiple fields for non-variable Span components?

[Diggsey]

Mostly just curiosity as it wasn't covered in the FAQs. Seems like using multiple fields comes at quite a large cost in struct size?

[BurntSushi]

There is some mention of it here: #17

And as a result of Span being large, this issue is also relevant: #21

And then finally, the use of ranged integers internally is also a constraint here: #11

The distinct fields of Span in terms of representation isn't tied to the public API. So that is something that can change in a semver compatible release. The main reason I just did the simple approach for a field for each unit is that:

• It's, well, the simple approach. Even if some of the non-variable Span fields were packed into a tighter representation, it would save some space, but Span would still be very bulky. So I perceived the difference between "simple" and "packed" as not enormous. But maybe I'm wrong about that.
• Jiff's internal abstraction for ranged integers keeps track of min/max values when debug_assertions is enabled. It is an important tool for identifying overflowing arithmetic. If I were to pack the representation, then I think this would mean using non-ranged integers in their packed form in release mode and ranged integers in debug mode. This isn't crazy, but it just isn't where I started.

My suspicion is that the Span type has some room for improvement, but there will likely be performance floors that it won't be able to break through. And that in turn will motivate adding other APIs as discussed in #17 and #21.

[Diggsey]

The distinct fields of Span in terms of representation isn't tied to the public API. So that is something that can change in a semver compatible release.

That doesn't seem to be the case? eg. get_minutes could not be implemented as it is today if all the non-variable fields were combined into a single nanosecond field.

[BurntSushi]

Oh, I misunderstood what you meant. I thought you meant combining all of the primitive types into a packed representation, but otherwise keeping their existing size based on their limits. For example, minutes currently uses an i64, but it doesn't actually support utilizing all 64 bits. It only needs to represent the number of minutes between the minimum and maximum datetime. So there are some wasted bits that could be used by other units. In fact, only nanoseconds utilizes the full 64 bits.

But yes, just collapsing everything down into a single nanosecond field wouldn't work. Because 120 seconds is considered distinct from 2 minutes.