FixedDecimalFormatter and WeekCalculator should be conditionally loaded in datetime

[sffc]

#4204 landed DateTimePatternInterpolator that always loads a FixedDecimalFormatter. Most patterns need one. However, not all patterns do, such as patterns that seek standalone display names. So should we make the FixedDecimalFormatter optional?

Maybe add a new constructor like try_new_without_fixed_decimal_formatter?

[sffc]

Bikeshed for the function name:

• try_new_without_fixed_decimal_formatter
• try_new_without_decimals
• try_new_without_number_formatting
• try_new_bare

Opinion @zbraniecki @Manishearth @robertbastian ?

[Manishearth]

3 > 2 > 1 >> 4

[robertbastian]

So what happens if you need a FDF but used this constructor? I like the try_new_without_number_formatting concept, but then it should do naive fixed decimal formatting instead of erroring.

[sffc]

It would have the same behavior as if you gave the DateTimePatternInterpolator a pattern that needs abbreviated month names but you didn't load abbreviated month names (returns a MissingDateNames error).

[robertbastian]

3 > 1 > 2 >> 4

[Manishearth]

Zibi also suggested try_new_without_numbers in the meeting

[sffc]

Ballots: https://docs.google.com/document/d/1cwObpQ_gdCsoZVEDNV7C-7eODxElGIJ3FNdivlbLnNo/edit

Results: Option 3, try_new_without_number_formatting, wins. It is the first choice of 5 of 6 ballots and has no vetoes.

[sffc]

Could possibly be done with field sets.

[sffc]

I'm opening a PR where I do this for DateTimeNames.

It's not immediately clear to me how to do this for field sets via the type system. I think I need the trait to optionally take a FixedDecimalFormatterLoader, but that is not currently public, and I've gotten pushback before when I tried to make the cross-crate loader stuff public. So, I would like to move the field set portion of this issue out of the 2.0 milestone. I propose putting it in Backlog.

[Manishearth]

fine by me