Index Month enum from 1

[pitdicker]

For 0.5 I'd like to make the Month enum less useless.

By defining Month::January as 1 users can do simple casting, and use it for example in:

let date = NaiveDate::from_ymd(2015, Month::March as u32, 14);

We can also choose to make Datelike::month return Month (#727). I didn't do so here for two reasons:

• For my personal projects using integers for months was perfectly fine and matches that year() and day() also return integers. I find working with integers more convenient than wordy month names.
• Returning en enum will introduce extra checks in the month method on NaiveDate that can't be optimized out without unsafe code. We know Mdf::from_ol(/* ... */).month() will reaturn a value in 1..=12, but the compiler doesn't.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.01%. Comparing base (08c9792) to head (bb658ae).
Report is 5 commits behind head on 0.5.x.

Additional details and impacted files

@@            Coverage Diff             @@
##            0.5.x    #1551      +/-   ##
==========================================
+ Coverage   93.98%   94.01%   +0.03%     
==========================================
  Files          37       37              
  Lines       16656    16579      -77     
==========================================
- Hits        15654    15587      -67     
+ Misses       1002      992      -10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djc]

Hmm, should we also make this explicitly repr(u8) then?

[pitdicker]

As I understand it the only extra thing repr(u8) on an enum allows is unsafe pointer casting.

[djc]

Maybe, but to me it's also like a signal to the users about how this type works?

[pitdicker]

With repr(u8) it no longer has niche optimization, but I suppose there is little use for that.

[djc]

Okay, I would actually say that's a good reason not to add it.

[djc]

Should we change at_ymd_and_hms() (and other places) to take u8 for month?

[pitdicker]

I don't know. A number of methods could take smaller arguments, such as NaiveTime::from_hms. Is there an advantage for users in taking a smaller type?

[djc]

Smaller types would probably allow more optimization potential.

[pitdicker]

I'll investigate and open an issue or PR. It does mean users have to do potentially fallible casts more often, so I'm not sure it is better for egonomics.