Call UnwrapNumberFormat in NumberFormat.prototype.formatToParts

[ryzokuken]

As we see in:

1. get Intl.NumberFormat.prototype.format (https://tc39.github.io/ecma402/#sec-intl.numberformat.prototype.format)
2. Intl.NumberFormat.prototype.resolvedOptions () (https://tc39.github.io/ecma402/#sec-intl.numberformat.prototype.resolvedoptions)

Intl.NumberFormat.prototype.formatToParts should also call UnwrapNumberFormat as the two mentioned above instead of:

3. If nf does not have an [[InitializedNumberFormat]] internal slot, throw a TypeError exception.

/cc @gsathya

[gsathya]

I'm not sure if we want to add the Unwrapping here, as the unwrapping behavior was mostly a fix for the legacy mistake.

I'm interested in understanding why we decided not to add the Unwrapping behavior here in the first place?

cc @anba @littledan

[littledan]

As @gsathya says, the unwrap logic is a legacy hack. I'd rather not add it to new things.

[ryzokuken]

It is functionally the same either way, though. I guess consistency isn't a strong enough ground to change it?

[littledan]

Consistency is an important goal in general, but the design principle with this unwrapping stuff is to do as little of it as possible. See #57 for the agonizing history.

[ryzokuken]

@littledan got it! Closing this.

[gsathya]

@littledan I'm still confused why there is discrepancy in methods that do unwrapping. Why does NumberFormat.prototype.format do the unwrapping whilst NumberFormat.prototype.formatToParts does not?

[littledan]

@gsathya Because legacy code uses format and expects it to be usable this way, whereas formatToParts was added later.