Should NeoFormatter and TypedNeoFormatter have default generics?

[sffc]

Currently if you want a time formatter you need to explicitly set the calendar type to NeverCalendar / ().

This raises the general question, should they have default generics?

The time formatter specific concern can also be addressed by

1. Make a type alias such as pub type TimeFormatter
2. Make format_time imply this bound

@Manishearth @robertbastian

[Manishearth]

I don't really think there's a sensible "default" here. I think TimeFormatter is fine. I also think adding the bound may work, though it would be nice if DateTimeFormatter could format_time too.

[sffc]

This currently works:

TypedFormatter::try_new(
  locale,
  fieldset::YMD::with_length(Medium)
)
.format(Date::try_new_gregorian_date(...))

This currently requires an explicit NeverCalendar:

TypedFormatter::<NeverCalendar, _>::try_new(
  locale,
  fieldset::HM::with_length(Medium)
)
.format(Time::try_new(...))

If we had format_time (#5269 (comment)), the type inference should work because the function would be defined on Formatter<NeverCalendar>

TypedFormatter::try_new(
  locale,
  fieldset::HM::with_length(Medium)
)
.format_time(Time::try_new(...))

[sffc]

What would pub type TimeFormatter map to?

pub type TimeFormatter<FSet> = TypedFormatter<NeverCalendar, FSet>
pub type TimeFormatter<FSet> = Formatter<FSet>
pub type TimeFormatter = TypedFormatter<NeverCalendar, TimeSkeleton>

[sffc]

I don't consider this a 2.0-beta blocker.

[sffc]

Shane/Rob discussion:

@sffc Note: I have already replaced NeverCalendar with (). We currently have:

DateTimeFormatter<_>  // field set
FixedCalendarDateTimeFormatter<(), _>  // calendar, field set

Discussion:

• @robertbastian - We could add a type alias for TimeFormatter<FS> = FixedCalendarDateTimeFormatter<(), FS> so that the weirdness is a bit more hidden
• @sffc It applies to time and time zone.

Bikeshed:

1. TimeFormatter
2. NoDateFormatter
3. NoCalendarFormatter
4. DatelessFormatter
5. TimeFormatter + TimeZoneFormatter

Discussion:

• @robertbastian I think 5 is best, it adds a small amount of API but it's the names people will be looking for. You don't want to think about calendars at all if you try to format a time
• @sffc It's confusing that TimeZoneFormatter can format other things besides time zones. I'm okay with TimeFormatter to start. It's not that weird to say to use TimeFormatter to format a time zone.
• @sffc Observation: you would be able to construct a TimeFormatter<fieldset::YMD>, but there is no type that satisfies the bounds for the .format function.

Conclusion:

• Add a TimeFormatter type alias
• Do not add default generics

LGTM: @sffc @robertbastian