Remove Date::try_new_from_codes in 3.0

[sffc]

It is replaced by the more powerful Date::try_from_fields, which also returns a better error type.

[robertbastian]

I would like to keep try_new_from_codes around as a convenience method. try_new_from_fields requires more boilerplate to call:

Date::try_from_codes(None, 1972, MonthCode::new_normal(1).unwrap(), 31, cal)
// vs
Date::try_from_fields(
    types::DateFields {
        day: Some(31),
        month_code: Some(MonthCode::new_normal(1).unwrap())),
        extended_year: Some(1972),
        ..Default::default()
    },
    Default::default(),
    cal,
)

edit: actually because DateFields is #[non_exhaustive] this is even worse because you need to introduce an extra variable:

Date::try_from_fields(
    {
        let mut fields = types::DateFields::default();
        fields.day = Some(31);
        fields.month_code = Some(MonthCode::new_normal(1).unwrap()));
        fields.extended_year = Some(1972);
        fields
    },
    Default::default(),
    cal,
)

[sffc]

My assertion is that if you're doing manual construction like that, you should be using the calendar-specific constructors like Date::try_new_hebrew.

because DateFields is #[non_exhaustive] this is even worse

It's unfortunate, but Rust limitations of this sort should not feed into our API design.

[robertbastian]

My assertion is that if you're doing manual construction like that, you should be using the calendar-specific constructors like Date::try_new_hebrew.

Those constructors are not usable generically though.

It's unfortunate, but Rust limitations of this sort should not feed into our API design.

Rust limitations should absolutely feed into our API design, we're designing Rust APIs.

[sffc]

My assertion is that if you're doing manual construction like that, you should be using the calendar-specific constructors like Date::try_new_hebrew.

Those constructors are not usable generically though.

If you're using it generically, you are probably plumbing data from some external source, and try_from_fields is more appropriate since it can handle more shapes of data.

It's unfortunate, but Rust limitations of this sort should not feed into our API design.

Rust limitations should absolutely feed into our API design, we're designing Rust APIs.

"Bags of parameters not supporting ..default" is a Rust limitation that doesn't stop us from using that pattern everywhere, because there is a path to eventually fix it via an RFC, we just haven't prioritized pushing for the RFC.

If the Rust limitation has no clear path to being fixed in the near term, like specialization, then we build around it.