Decide what to do with stability of CldrCalendar trait in 1.5

[sffc]

#4204 landed a change to CldrCalendar that adds two new associated types with #[cfg(feature = "experimental")]. CldrCalendar is a public trait because it shows in public bounds.

This is a breaking change but also the only way we can finish neo date symbols (#3865). Discuss what to do.

[Manishearth]

If we decide to break it we should also just seal it.

[sffc]

• @sffc - I see a few directions:
  • 1. Change the trait and hope we don't break anyone
  • 2. Duplicate the trait and all code that uses the trait, and delete the old code in 2.0
  • 3. Keep the associated types behind a feature flag
• @hsivonen - I'm not in favor of churn for cases we don't know are concrete and not theoretical.
• @Manishearth - We don't expect anyone to implement this trait, it's not very implementable and it's not useful. It's very niche to write your own calendar. So overall I don't expect this is an API for anyone to be using, and I'm fairly confident no one is using it.
• @robertbastian - Does sealing the trait solve the issue?
• @Manishearth - There's not a way to solve the problem without a breaking change. If we decide to break, we should go ahead and seal the trait. Which is also why I'm fairlry confident no one is implementing it yet, because it's hard to implement.
• @sffc - If we seal it, then we prevent third-party implementations. It seems more useful to leave it with a warning, but leave it implementable for people who want to do so at their own risk.
• @Manishearth - I'd seal it in a way you can get past, such as implementing a method named _unstable_sealed or something like that. And we document what that means. Or we could make a function that returns a private type that is public in cfg(feature = "experimental").
• @sffc - How about naming the function _unstable
• @robertbastian - Or we could make the trait extend an InternalBeCareful trait. Then you don't have a method that doesn't do anything on the trait. A method gets autocompleted, etc. Seems like we should avoid that.
• @robertbastian - I remember reading 3 ways to do sealed traits in Rust. The method, the parent trait, and one more, and they all have different semantics.

https://predr.ag/blog/definitive-guide-to-sealed-traits-in-rust/

• @Manishearth - I think we don't need to discuss how we seal the trait right now. As long as we decide that it's okay to break the trait, we consider the trait experimental and unstable, and switch between sealing methods.
• @sffc - Can we just leave the repo in its current state, and document the trait as being unstable?
• @Manishearth - No, we should explicitly seal it.
• @sffc - I think it should be unstable with the same guarantees as the provider module.

Conclusion:

• Break the trait in 1.5
• Seal the trait. Exact mechanism can be up to the PR author. As long as the datetime crate has an "experimental" feature, users should need to enable that feature in order to implement the trait, and if they don't have the feature enabled, the trait should not be implementable from userland code. If/when the "experimental" feature is removed from the crate, we should re-litigate the exact mechanism around how to make the trait unstably implementable. Exact mechanism can be changed an arbitrary number of times until we remove the "experimental" feature. We will make a follow-up issue to discuss that. Repo becomes releasable after it is a sealed trait on non-experimental.

Agreed: @robertbastian @Manishearth @hsivonen @sffc

[sffc]

We can use #4338 as the follow-up issue.