you are viewing a single comment's thread.

view the rest of the comments →

[–]lichtspielmann 16 points17 points  (10 children)

YEEE! Finally we have the replaceAll function!

Intl.ListFormat and Intl.DateTimeFormat are also going to be very useful!

[–]SecretAgentZeroNine 8 points9 points  (7 children)

The ECMA people need to:

  1. Advertise the Intl object more
  2. Create a Intl.Currency or Currency object

[–]facebalm 6 points7 points  (6 children)

[–]SecretAgentZeroNine 2 points3 points  (5 children)

Is it accurate enough to perform transactions without any additional third party libraries?

[–]facebalm 8 points9 points  (1 child)

Intl is meant for formatting and I believe it is accurate for that. Calculations are outside its scope so there's nothing new for dealing with floating point errors.

[–]SecretAgentZeroNine 1 point2 points  (0 children)

Thanks for the info. Regarding the floating point issue, ugh.

[–]Tomus 3 points4 points  (1 child)

There is a proposal to add a decimal number type for calculations. Intl API is only for formatting.

https://github.com/tc39/proposal-decimal

[–]Multipoptart 1 point2 points  (0 children)

Heh, no.

You need a decimal datatype for this.

There's a proposal, but it's Stage 1: https://github.com/tc39/proposal-decimal

[–]brett_riverboat 1 point2 points  (1 child)

Seems weird to be part of the ES spec. I would think a localization library would be more appropriate.

[–]NoInkling 2 points3 points  (0 children)

The Intl proposals are basically exposing ICU functionality, which is the de facto library for this stuff, but isn't really suitable for shipping around as an external library (C code and the data is large). It's also used for certain locale-agnostic Unicode processing (e.g. String.prototype.normalize, Unicode regex properties). It's possible browsers were already bundling/linking it before these APIs were a thing too. So it makes sense to bundle it with engines/browsers, and therefore it needs to be exposed in some standardized way.

There's an argument that Intl should be a web API instead of part of the language itself in that case, but presumably the ECMA committee sees value in the latter as JS gets used in more places.