Revert Intl.NumberFormat.formatToParts to Stage 3?

[littledan]

As far as I know, Intl.NumberFormat.formatToParts has one implementation, in Intl.js, but has not been implemented in any browser yet. @jswalden is working on it, but has run into some difficulties, partly because it seems that number parts nest in a way that date parts do not (and it's not clear whether the current spec handles this properly; maybe this was discussed with @zbraniecki). While Intl.DateTimeFormat.formatToParts is at Stage 4, I think Intl.NumberFormat.formatToParts currently only meets Stage 3 requirements, as there is currently work in progress on pioneering implementations which may help refine the specification.

[caridy]

@littledan according to @zbraniecki it was implemented in firefox, at least that is what we have in the notes from last meeting IIRC. I will be ok downgrading it until after it meets the criteria, I just want to make sure before we take any action.

Aside from that, @jswalden can you explain what difficulties have you encounter? I haven't receive any feedback on that regard, maybe we can work something out in the spec text.

[zbraniecki]

@littledan according to @zbraniecki it was implemented in firefox

The DateTimeFormat part was, the NumberFormat part is currently being implemented by @jswalden.

I'm fine with separating those two based on implementation status.
But I doubt we will want to alter the specification at this point.

@stas wrote the Intl.js implementation and drafted the spec - what do you think?
@jswalden - what's your recommendation?

[littledan]

The process document requires two implementations, not one. I think there's value in that in the ECMA 402 context--we get real additional value out of trying out integrating the spec with a native Unicode library which is more complete than Intl.js in terms of refining the spec.

[zbraniecki]

Agree, it's my fault. I apologies for that.

I'd still like to understand better what are the difficulties @jswalden encountered. Last time we talked we discussed how ICU creates parts of Number string differently than for DateTime (by creating a hierarchical tree instead of consecutive parts) but that's not in the scope of formatToParts and I doubt it will affect the spec.

The reason why I'd like to understand this before we take any action is that if we have a reason to believe that we want to change the spec based on the experience of implementing it in Firefox, I believe we may want to act differently than if the spec remains the same and the implementation in Firefox is going to land soon.

Once again, it's my fault, I'm just trying to figure out how to move forward now and if we can salvage the idea of having formatToParts in both formatters for the next release of the spec.

Also, if we'll decide to back out, can we follow @littledan advice and just backout the public API method, while preserving the internal logic updates? This is super helpful for other proposals to build on.

[caridy]

#102

[stasm]

@stas wrote the Intl.js implementation and drafted the spec - what do you think?

Chiming in late. I wasn't involved in the planning but I support @littledan's request. Let's not rush things here.

@jswalden is working on it, but has run into some difficulties, partly because it seems that number parts nest in a way that date parts do not (and it's not clear whether the current spec handles this properly; maybe this was discussed with @zbraniecki)

I wasn't aware of these problems. Is there a bug/issue on file for this?

[bterlson]

Without two implementations this shouldn't be stage 4.

[littledan]

I think this bug should be closed as fixed, as the 402 draft spec now doesn't include NumberFormat.prototype.formatToParts. Probably it'd be good to mention this in the 402 status update at the next TC39 meeting.

[caridy]

I have updated the readme, we should be good now!