Re: Why aren't interpolation values in tagged template calls saved as a cached array?

There is no "interpolation values array"; a tag function receives a single frozen array of static template contents (unique per call site) and a distinct argument for each substitution value. Source code can collect them *into* an array by use of ... "rest" syntax, but every evaluation of that

Re: Proposal: Tagged Constructor & Taggable Function/Map/Set constructor

That syntax is already valid, and has a different meaning. new ctorFactory`…` first evaluates the tagged template (invoking ctorFactory with arguments derived from the template literal) and then invokes that result as a constructor. For example, (new ctorFactory`return function Ctor(){}`).name

Re: Expectations around line ending behavior for U+2028 and U+2029

The only explicit mention of line numbers in the spec is to note that "… should be considered a single SourceCharacter for the purpose of reporting line numbers", but it's clear from things like ASI and termination of single-line comments that every *LineTerminatorSequence* is equal in this sense.

Re: JSON.parse should be simple and idiot-proof

t; // (without parse-as-BigInt) → 0.65625 // (with parse-as-BigInt)→ 0n We just silently lost floating-point arithmetic. On Sun, Oct 21, 2018 at 1:00 PM Isiah Meadows wrote: > This would be the correct understanding here, a 4th parameter read as a > boolean. > > On Sun,

Re: JSON.parse should be simple and idiot-proof

First, note that reviver functions *do* manipulate the result after it's parsed. Second, "parse ints as bigints" is too big a hammer—changing the output for all numbers would break currently working code. And third, it's not even fully sufficient for the "big numbers" purpose, which logically also

custom cross-realm brand checking

Responses inline. On Monday, October 1, 2018, Jordan Harband wrote: > Function.prototype.toString wouldn't suffice as a verification - you could > reconstruct it with eval, in many cases > I've specifically constructed a use that I believe cannot be reconstructed in such a way, with or without

custom cross-realm brand checking

One of the topics discussed in the final breakouts of last week's TC39 meeting was something like "self-hosted implementation of cross-realm internal slots". I facetiously joked about using the global symbol registry (which is shared across realms), but it was pointed out that such a mechanism

Re: javascript vision thing

se JSON.parse doesn't expose the text used to produce a value. But in my opinion, it would be a mistake to characterize that explicit lack of support as "limbo". On Sat, Jul 28, 2018 at 1:02 AM Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-07-28 00:34, Richa

Re: javascript vision thing

As stated even more strongly in ECMA-404: > > Because it is so simple, it is not expected that the JSON grammar will > ever change. This gives JSON, as a foundational notation, tremendous > stability. On Thu, Jul 26, 2018 at 9:43 AM Jordan Harband wrote: > That's a ridiculous claim,

Re: Promise capability support

On Fri, Jul 20, 2018 at 12:15 PM Augusto Moura wrote: > Interesting enough, I got a really weird case (reads contraintuitive, I'm > pretty sure the semantics of the error are right) extending the Promise > class to exemplify a simple Deferred implementation, the code: > > ``` js > class Deferred

Re: Proposal seeking champion: Uniform parsing of quasi-standard Date.parse input

important to specify what must be *rejected*. Think of it like an error-correcting grammar. On Friday, June 29, 2018, Jordan Harband wrote: > See also https://github.com/tc39-transfer/proposal-date-time-string-format > > On Fri, Jun 29, 2018 at 1:01 PM, Richard Gibson > wrote: >

Proposal seeking champion: Uniform parsing of quasi-standard Date.parse input

TL;DR: https://github.com/gibson042/ecma262-proposal-uniform-interchange-date-parsing A conversation bubbled up on IRC a while back about how implementations handle unusual Date.parse input, and I've been thinking about it on and off ever since. It turns out that engines are all over the place

Re: "Stupid" JSON Number Serialization Question

That seems like a question best addressed by something like JSON Schema. ECMAScript is not unique in lacking sufficient native machinery to process JSON numbers that have no IEEE 754 64-bit representation, and similar issues exist for binary data and complex types like date/time values. On

Re: JSON.canonicalize()

but is not the only option (e.g., another option is using the literal characters of the JSON text such that "Z" < "\"" < "\\" < "\u" < "\u001F" < "\uD800" < "\uDC00" < "^" < "x" &

JSON.canonicalize()

On Sunday, March 18, 2018, Anders Rundgren <anders.rundgren@gmail.com> wrote: > On 2018-03-16 20:24, Richard Gibson wrote: > > Though ECMAScript JSON.stringify may suffice for certain > Javascript-centric use cases or otherwise restricted subsets thereof as &

Re: JSON.canonicalize()

Though ECMAScript JSON.stringify may suffice for certain Javascript-centric use cases or otherwise restricted subsets thereof as addressed by JOSE, it is not suitable for producing canonical/hashable/etc. JSON, which requires a fully general solution such as [1]. Both its number serialization [2]

Re: Suggestion: Destructuring object initializer.

I'm unsure if `Object.assign(a, b)` and `{...a, ...b}` are equivalent in terms of optimization opportunities, but I am certain that they are not equivalent *in *every* regard* because Object.assign invokes setters but object spread does not. cf.

Re: Re: RegExp.escape()

Or even better: `(?]**foo)` ("]" still terminates character classes; "**" is a less ugly normally-invalid sequence). On Tue, Dec 5, 2017 at 11:25 AM, wrote: > Reviving this [thread] a third time, is there any love left for > introducing RegExp.escape? The previous

Re: Re: RegExp.escape()

Reviving this [thread] a third time, is there any love left for introducing RegExp.escape? The previous attempt was abandoned because of a so-called "[even-odd problem]", but that can be fixed: backslash-escape every _SyntaxCharacter_, then wrap the full result in a new form of non-capturing

Re: Re: RegExp.escape()

Reviving this [thread] a third time, is there any love left for introducing RegExp.escape? The previous attempt was abandoned because of a so-called "[even-odd problem]", but that can be fixed: backslash-escape every _SyntaxCharacter_, then wrap the full result in a new form of non-capturing group

Re: JSON text is not a subset of PrimaryExpression

ld have been > then. Nevertheless, I would still be in favor. > > Please draft a proposal. Thanks. > > > On Jul 18, 2017 8:16 PM, "Richard Gibson" <richard.gib...@gmail.com> > wrote: > > Another relevant option: Feature Request: Make ECMA262 a superset of JSON >

Re: JSON text is not a subset of PrimaryExpression

Another relevant option: Feature Request: Make ECMA262 a superset of JSON On Tue, Jul 11, 2017 at 9:33 AM, Mike Samuel wrote: > https://tc39.github.io/ecma262/#sec-json.parse says > >

Re: Feature Request: Make ECMA262 a superset of JSON

se claims in §24.3.1 <https://tc39.github.io/ecma262/#sec-json.parse> of JSON being a subset of ECMAScript literals. U+2028 and U+2028 would still be line terminators for purposes of ASI/line numbering/etc., but would be allowed unescaped in string literals. On Sun, Oct 16, 2016, 22:08 Richard

Re: Feature Request: Make ECMA262 a superset of JSON

implemented in browser. That prevents definitely > to "safely" embed arbitrary JSON within JS. > > —Claude > > Le 29 sept. 2016 à 23:21, Richard Gibson <richard.gib...@gmail.com> a > écrit : > > ECMAScript claims JSON as a subset twice in https://tc39.github.io

Feature Request: Make ECMA262 a superset of JSON

ECMAScript claims JSON as a subset twice in https://tc39.github.io/ecma262/#sec-json.parse , but (as has been well-documented) that is not true because it JSON strings can contain unescaped U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR while ECMAScript strings cannot. Mark Miller alludes to