ToSpan for all number primitives

[janTatesa]

I don't see the reason why ToSpan has to be implemented for only some signed integers

[BurntSushi]

Can you elaborate on your use case? Why do you want it implemented for unsigned integers?

(My approach to API design is not "why not," by "why do.")

[janTatesa]

Simply so that I don't have to always convert my variables to a signed integer. While it's true that I should use the try methods instead, the code is infallible as I have an u16 and use the days function. Using that same logic, why support it for i64? The only reason a person would pass an i64 to any of these functions is if they were stored in a variable, because if it was a literal which is larger than the limits, the code would be explicitly failing.

[BurntSushi]

Not sure what you mean by i64. The full range of i64 is supported for nanoseconds.

I'm not sure your reasoning justified the extra impls. I'm worried about possible inference problems, although I'm not sure they exist.

I also somewhat feel like your use case is a little niche. This trait is intended to be used with integer literals as a convenience because of panicking. In that circumstance, the unsigned integer impls don't seem well motivated.

I'm open to this if someone can articulate a more compelling use case.

[janTatesa]

So what would you do if you have an u16 specifying a number of days and you want to add it to a date?

[BurntSushi]

I would use Span::new().days(number). Or i32::from(number).days().

I'd like to re-emphasize this point:

This trait is intended to be used with integer literals as a convenience because of panicking.