Fallback behavior for measure units

[sffc]

What should happen if you call the API with a unit identifier that the implementation doesn't know about?

A few options, each with pros and cons:

1. Put the list of supported unit identifiers directly into the spec
   • Pro: No ambiguity as to which units are available
   • Con: Difficult to update; can't just push new units as soon as they become available in CLDR/ICU
2. Throw an exception if the implementation does not know about the unit
   • Pro: The user gets a signal and can deal with that case on their own
   • Con: Some browsers could throw exceptions and others not throw exceptions with the same code
3. Use the unit identifier itself as the fallback: "3 length-meter"
   • Pro: Well-defined, exceptionless fallback behavior
   • Con: The string output is not localized and not particularly clear

Thoughts?

[sffc]

The Ecma 402 committee wants to have a list in the spec of a minimum set of units that an implementation must support.

This still leaves open the question though of what behavior to adopt when using a unit identifier outside of the minimum required set.

1. @srl295 suggested doing our best to localize the unit identifier; for example, CLDR should have translations for the "length" part of the string.
2. Another option could be to strip off the type part and display just the unit part ("meter" instead of "length-meter").
3. Throw an exception if you don't support the unit: some implementations might throw where others don't.
4. Throw an exception for any unit not in the spec set, even if the implementation supports it: slower updates, and there could still be cases where some browsers throw where others don't, because some browsers may pull in spec updates sooner than others.

[littledan]

I'd like to put in a vote for option 4. It seems the most reliable to me. When more units are added, it would be an explicit and shared action by the group, rather than an implementation-specific thing. Since we have a standing group, it should not be hard to add units.

[sffc]

Hmm. So with option 4, it requires explicit action from TC39 in order to add the additional units. Units get added somewhat frequently, a handful each year. Presumably the update could be a PR directly to the spec without a separate proposal. It still requires a human to take action, though.

With all other options, no human action is required to support new units as they become available in ICU (other than updating ICU itself).

[littledan]

Making that explicit change whenever there are more units to support sounds good to me. We settled on this policy for Unicode properties in RegExps, cc @mathiasbynens.

[mathiasbynens]

+1 — explicit > implicit.

I’ve been posting an overview of what’s new in Unicode X for ECMAScript in the form of tracking issues such as tc39/ecma262#1219. PRs such as tc39/ecma262#1218 update the list of Unicode properties in RegExps. I’d love it if we can do the same thing here.

[sffc]

Following the precedent set by Unicode properties SGTM. Thanks for finding that.

I'll update the proposal spec text soon.

[zbraniecki]

+1 — explicit > implicit.

+1

[sffc]

I am re-opening this issue just briefly.

With the new "core unit identifier" syntax, users are now passing strings like "meter" instead of "length-meter". The new core unit identifiers are a little bit more user-friendly.

@rxaviers pointed out previously that throwing an exception for an unknown unit is inconsistent with what we do with unknown currency codes, which is to echo out the currency code itself. The argument for the difference was that there was not a reasonable way to display the unit identifiers. However, the simplified core unit identifiers may be "good enough" that we can use those as the fallback symbols.

Thoughts?

[sffc]

Re-affirmed the previous consensus at today's Ecma 402 meeting.