Could consider using `usize` for the inner type of `Size`?

[kevinchannon]

In general, when talking about numbers of bytes and things like that, we don't care about negative numbers of bytes, so an unsized type could be good. Also, usize is specifically for representing the size of things. I think.

If a signed thing is necessary, then perhaps it could have a different type. For example, Offset could be defined with i64 as it's inner. An Offset could also be the result of a Size +/- some value.

Maybe Size could be generic on the type and constrain it to be some arithmetic, integer value?

Alternatively, a method like Size::ubytes() could return the size as an unsigned value? I just have a bunch of functions that take a value as an unsigned number of bytes, so I'd have to do a lot of casting everywhere to replace them with Size values, which I want to do :)

[mqudsi]

Thanks for opening an issue and sharing your interest. Using usize is out of the question as there's no link between an architecture's pointer size and the size of files or the size metadata when processing size-related information that a library/app will encounter; we would effectively run into the same legacy limitations of apps using long under C/C++ on 32-bit platforms would where sizes would wrap over (or the app would crash if checked arithmetic is enabled) when handling files greater than 4 GiB on 32-bit platforms.

Using u64 specifically would be a different request, but briefly, no there's no current interest in switching over to something that would complicate the internal logic (as we fully support arithmetic on Size types) and might affect how sizes are (de)serialized or parsed from textual representation. (The initial version of this library did use a generic type to store the size, but that was considered to be an overly complicated interface and led to type-specific limitations.)

The good news is that your suggestion of adding a ubytes() method that returns an unsigned u64 value instead of the signed i64 value would be something I'd be open to. I'd have to study the edge cases, but I'm not against it in principle -- though we would have to define its behavior when handling negative values as off the top of my head I cannot make a good case for returning their unsigned representation.