Editorial: Layer locale processing under Intl.Locale

[littledan]

This patch consolidates the Intl specification by unifying the
places where language tag strings are parsed and produced: All
processing is moved to the core of the Intl.Locale constructor.
This

Options processing is still left not unified between Intl.Locale and
other Intl constructors. This is because the semantics of other
Intl constructors are significantly different from Intl.Locale
in multiple ways:

• Unicode tags such as "ca" fall back to locale-specific defaults
• Tags are checked for presence of locale data, falling back to
  another value if not data is not present
• resolvedOptions() has a locale property which expresses the part
  of the given language tag that was used. It's unclear whether
  changing this would risk compatibility.

Closes #31

[littledan]

cc @nciric

[nciric]

Do we even have resolvedOptions() for Intl.Locale?

[littledan]

@nciric Nope

[anba]

I'm a bit sceptical about using actual Intl.Locale instances for internal operations when the instance is never visible to content code, because

1. It reminds me of the first 402 editions which made extensive use of Objects and Arrays which only made things more complicated when compared to using Records and Lists.
2. And it may not reflect what implementations actually end up with using internally and thus increasing the disparity between the spec and its implementation. For example in SpiderMonkey I would try very hard not to create Intl.Locale instances and instead use different internal representations where possible.

What I'd probably do instead is to create a Record (with a named schema) to represent language tags and then pass that language tag Record around, because Records feel like a better marker for implementors to signal that they are free to choose the data structure. Intl.Locale instances would also store their current internal slots using that Record. So basically a separation of concerns thing...

(Full disclosure: Maybe I'm just biased and prefer that other approach, because it better reflects what I've already implemented in two engines.... 😄 )

Apart from that

• The PR makes intensive use of If-Otherwise instead of the more common If-Else. That should probably be changed to If-Else.
• The ResolveLocale algorithm seems incorrect and should be double-checked, for example it overwrites the default value stored in the value variable.
• The Intl.Locale constructor no longer validates its arguments from left to right, because the language tag validation is now moved into CreateLocale. That seems a bit unfortunate, because we normally try to validate all arguments from left to right (in ECMA-262 and ECMA-402). That means I'd prefer if IsStructurallyValidLanguageTag is moved back into the Intl.Locale constructor and an assertion is added to CreateLocale that the tag parameter is already a validated language tag. (Obviously that means IsStructurallyValidLanguageTag also needs to be added to CanonicalizeLocaleList.)

[littledan]

We discussed this PR in the May 2018 Intl meeting. The conclusion was that the locale parsing logic should be shared between Intl.Locale and ResolveLocale, but that the latter shouldn't actually be represented in terms of the former. Does anyone want to write this up in a PR?

[littledan]

Closing per #36 (comment) .