Consider un-deprecating the Hijri and Chinese calendar aliases or making them newtypes

[sffc]

We have a lot of type aliases in ICU4X.

Why should we mark the new type aliases (which were previously their own structs) as deprecated? Why not just embrace that they each represent their own CLDR calendar?

https://github.com/unicode-org/icu4x/blob/main/components/calendar/src/cal/mod.rs

Alternatively, I would maybe be slightly more comfortable if we made them newtypes with a private inner field, so that we can change the implementations again in the future. It means that we'd need to delegate a bunch of trait impls, which is annoying, but that's just how Rust works. On the bright side, it would resolve issues where we have bespoke ICU4X functionality that we don't want on the public trait, like CalendarAlgorithm (#6960) and reference year (#6959).

@robertbastian @Manishearth

[robertbastian]

I had to deprecate HijriUmmAlQura::new, because now that it is a type alias, we shouldn't have multiple new methods on the Hijri type. So if you have to call HijriUmmAlQura::new_umm_al_qura, you might as well just call that on Hijri.

Alternatively, I would maybe be slightly more comfortable if we made them newtypes with a private inner field

This would be horrible. There would be no way to implement something like datetime (but also user code) for all Hijri calendars. One would always have to remember also adding the three newtype calendars on top of the blanket impl. This would also apply do Date constructors, we finally only have one Hijri Date constructor.

[robertbastian]

issues where we have bespoke ICU4X functionality that we don't want on the public trait, like CalendarAlgorithm (#6960)

let's finish that discussion first before making such statements.

[sffc]

something like datetime

I assume you mean datetime formatting?

That's a can of worms I didn't comment on because it needs a ton more design, and very likely a new trait anyway in the datetime crate. I don't think we can assume that newtypes preclude us from formatting custom Hijris.

[robertbastian]

I don't think we can assume that newtypes preclude us from formatting custom Hijris.

not what I said

[Manishearth]

I agree with @robertbastian that newtypes for Hijri would defeat the point of the custom pluggable Hijri stuff.

(I'm more amenable to that argument for Chinese/Dangi)

Why should we mark the new type aliases (which were previously their own structs) as deprecated? Why not just embrace that they each represent their own CLDR calendar?

I actually think it's fine to have the type aliases. And it's also okay to have multiple new() functions each implemented on a concrete specialization, Rust allows for that! I don't think the existing API needs to be deprecated.

[robertbastian]

I actually think it's fine to have the type aliases. And it's also okay to have multiple new() functions each implemented on a concrete specialization, Rust allows for that!

So we'd have HijriUmmAlQura::new() and Hijri::new_umm_al_qura(), two ways to do the same thing (I do want new_umm_al_qura so that Hijri::new_ autocompletes all options). We'd also have Hijri::new() and Hijri::new(), two identical ways to do different things (depending on whether the associated type can be inferred, otherwise the compiler throws an error). I don't think that's ideal, which is why I deprecated the aliases.

[Manishearth]

I'm okay with "two ways to do the same thing" for convenience types.

I actually think the multiple valency of Hijri::new() is a feature: it makes it clear that there are multiple calendars and you need to specify more info.

[Manishearth]

The reason we added the Hijri type is for people to be able to plug things in, not because we thought a merged Hijri type was a better API. It's a smaller API, but most people will either want one specific calendar or AnyCalendar when doing locale-based stuff. The merged calendar is, to me, a slightly worse API, that we are accepting the cost of because we want things to be pluggable (and I don't really want us to make a separate public PluggableHijri type that is not publicly used by the other calendars, I prefer the merging to that). So it's slightly worse, but it's fine, but that doesn't mean I want us to make further merge-shaped choices via deprecating the per-calendar things.

[robertbastian]

I think the merged calendar is a better API, because you can now implement things (like formatting) for all Hijri calendars.

[Manishearth]

@robertbastian Yes, but is it a better API for people who wish to just use one calendar? Someone who wants a UAQ calendar on their website is better served by a straightforward UAQ type and constructor. I think the new API is fine for this purpose.

I'm amenable to us weighting "one way to do a thing" over convenience here, but I do want us to acknowledge that the convenience APIs are more convenient when making that tradeoff.