Decorator-based extended numeric literals

Daniel Ehrenberg

Igalia

In partnership with Bloomberg

January 2019 TC39

Goals of this presentation

• Explain decorator-based extended numeric literals.

​

• Get the committee's feedback on the proposal.

​

• If this alternative seems potentially feasible,�re-promote _ as a numeric separator to Stage 3.

Motivation: Generalize new numeric literals

• Built-in:
• 1236536253453n BigInt
• Extended:
• 4525@i Imaginary numbers
• 235435.461@m User-defined Decimal
• 300@px CSS Typed OM

Syntax

PrimaryExpression[Yield, Await] :� ...� ExtendedNumericLiteral��ExtendedNumericLiteral ::� NumericLiteral @ IdentifierPart Arguments_opt�

• Suffix must start with @ (It's a little mini-decorator!)
• No complex expressions allowed
• No whitespace between Number and suffix
• Numeric part uses Number grammar

​

Semantics

decorator @i { @numericTemplate(impl) }

1234@i

→

impl(Object.freeze({string: "1234", number: 1234}))

​

​

• Object is cached just like tagged templates
• Use in WeakMap to avoid re-parsing work

​

​

Why decorators?

• Literals and decorators are both static--a natural fit
• Potentially usable for new built-in types, as the use of a decorator gives more static information than a function call
• Allows the parser to generate and cache the numeric value, as it does for Number and BigInt today.
• No name mangling required, as @ is part of the name
• You're unlikely to have a clashing @i or @px in local scope!

Removes ambiguity with numeric separators

• @ is used in this proposal, and _ in numeric separators
• Previous drafts also used _ to avoid visible name mangling
• If decorators are a promising path, no reason to pursue 123_suffix
• In this case, can we restore numeric separators to Stage 3?

Status

• Explainer
• No spec, implementations or tests
• Currently Stage 1

Does this path seem promising?

​

Can we restore Numeric Separators to Stage 3?