profile
viewpoint
Ecma TC39 tc39 The web https://www.ecma-international.org/memento/tc39-rf-tg.htm Ecma International, Technical Committee 39 - ECMAScript

tc39/ecma262 10368

Status, process, and documents for ECMA-262

tc39/ecmascript-asyncawait 1542

Async/await for ECMAScript

tc39/proposal-async-iteration 799

Asynchronous iteration for JavaScript

tc39/agendas 571

TC39 meeting agendas

tc39/proposal-bigint 539

Arbitrary precision integers in JavaScript

tc39/ecmascript_simd 514

SIMD numeric type for EcmaScript

tc39/ecmascript_sharedmem 338

Shared memory and atomics for ECMAscript

tc39/ecma402 295

Status, process, and documents for ECMA 402

tc39/proposal-array-last 227

A JavaScript TC39 Proposal for getting the last element from an array

tc39/proposal-asset-references 224

Proposal to ECMAScript to add first-class location references relative to a module

pull request commenttc39/proposal-temporal

Add TypeScript types to polyfill

Fixed a mistake from last night's commit: unlike compare, the equals methods are instance methods, not static. Ignore the first commit message from this morning-- it had a typo and I amended.

justingrant

comment created time in 13 minutes

push eventtc39/proposal-temporal

Philipp Dunkel

commit sha 9a7743af5197fd873ef7d095af12ff99b879c0cd

Deploy tc39/proposal-temporal to github.com/tc39/proposal-temporal.git:gh-pages

view details

push time in 17 minutes

pull request commenttc39/ecma262

Editorial: Remove assertion in InitializeBinding of Object Environment Record

@bakkot It's used for the [[ObjectRecord]] of the global environment record.

jhnaldo

comment created time in 27 minutes

fork avandolder/test262

Official ECMAScript Conformance Test Suite

fork in 43 minutes

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

I gotta say, if the only cost on the arithmetic side is on the sign of infinities, I'm leaning ever farther towards normalizing -0 to 0 in records and tuples.

I don't think I'm in favor of normalizing -0 to 0. If the choice is between "Record and Tuple can store all primitives except for -0" and "-0 and 0 are not equal when inside a Record and Tuple", I would choose the latter.

bakkot

comment created time in 44 minutes

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

I don't think Map and Set deserve to be considered precedent for any decision here

It's not just them, what would be the most straitforward way to imitate Records and Tuples right now? String concatenation, or even JSON.stringify. But -0 doesn't survive it: Object.is(0, Number(String(-0))); Object.is(0, JSON.parse(JSON.stringify(-0))); So -0 normalization is nothing unusual, perhaps not very explicit.

bakkot

comment created time in an hour

pull request commenttc39/ecma402

Editorial: Add note for IsStructurallyValidLanguageTag

I'm kinda wondering why we have that paragraph at all. It's really redundant. Maybe that whole thing should be a note? It's not great to have normative text that's duplicated like that. @anba do you know?

The duplicate information was already present in the first edition. Except that at that time there wasn't any (semantic) difference between the bullet points and the text.

If I had to guess, I'd say the text was only added to explicitly define the return values of the function. And possibly to state that the duplicate singleton x in und-x-x isn't an error.

It probably doesn't hurt to keep:

Terminal value characters in the grammar are interpreted as the Unicode equivalents of the ASCII octet values given.

but even without that sentence the intent should be clear.

ryzokuken

comment created time in an hour

issue commenttc39/proposal-record-tuple

Names of `Tuple.prototype.*` methods

Collecting the above ideas and adding some more:

const x = #[2];
let y;

y = x.pushed(4);
y = x.toPushed(4);
y = x.asPushed(4);
y = x.withPushed(4);
y = x.copyPush(4);
y = x.clonePush(4);
y = x.copyAndPush(4);
y = x.cloneAndPush(4);
y = x.pushToCopy(4);
y = x.pushToClone(4);
rauschma

comment created time in an hour

issue commenttc39/proposal-pipeline-operator

Moving ahead with the minimal proposal

Please don't just focus on the rxjs community. At my place of work we have used the bind operator and eventually switched to the pipeline operator, but avoid currying functions. We use the pipeline operator, via Babel, primarily in two ways... Composing react components together, and simplifying complex transformations/computations of data, which we do a lot of in the client. Here, we're not so concerned with the idea of point free programming. We care about splitting up these computations into discrete, testable stages that are easy to maintain and a flow that is easy to read.

F# style makes things a bit harder/less convenient for us in pretty much every case. We'd have to write adapters to existing functions (or rewrite them if await is used). Hack and Smart seem to work well for us and how we use the pipeline.

Moving forward with any style helps us in some way as we expect better tooling support for a formally adopted JS feature. We'd all be happier if that were the case.

pygy

comment created time in an hour

issue commenttc39/ecma262

Error in B.3.3.6 Changes to BlockDeclarationInstantiation

cc @littledan and @anba in case either of you remember touching this part and can confirm.

Hmm, maybe that happened because I've implemented this part slightly different in es6draft? Anyway, the applied changes look correct to me! :-)

johnnygerard

comment created time in an hour

startedtc39/proposal-decimal

started time in an hour

issue commenttc39/ecma262

Should ECMAScript implementations be allowed to canonicalize NaN when writing into an Array?

Rather than guessing at the intent of that spec. text it would be better to take a look at the bugs.ecmascript.org issues (and meeting notes and possibly some es-discuss posts) that led to its creation. That's why we keep those records.

https://tc39.es/archives/bugzilla/3508/

littledan

comment created time in 2 hours

startedtc39/proposal-record-tuple

started time in 2 hours

startedtc39/proposal-record-tuple

started time in 2 hours

issue openedtc39/proposal-module-attributes

Unmixing type from other attributes

Having read through the other issues, I note that this part of the proposal isn't exactly accurate:

Another option considered and not selected has been to use a single string as the attribute, indicating the type. This option is not selected due to its implication that any particular attribute is special; even though this proposal only specifies the type attribute, the intention is to be open to more attributes in the future.

As currently envisioned, the type option is indeed special. It defines the loader to use to transform the resource into its imported form. Any other additional attributes are really arguments for that loader.

I mean, the reason there's a need for type in the first place is that we can't trust that a network request for a .json file actually resolves to be a JSON file; type is fulfilling the role that file extensions have traditionally taken.

Making a keyword-based type explicitly special would also provide a way for those attributes not to need to be defined inline and separately for each import, by providing a key to use in a central registry for other attribute defaults.

Finally, the simplicity of a string as value and the power of a with key:value set of attributes are not mutually exhaustive. Why not have both?

import.meta.registerType('custom', loadFunction, { some: 'attributes' })

import foo from './foo' as 'json'
import foo from './foo' as 'json' with foo: 'bar'
import foo from './bar' as 'custom'
import foo from './bar' as 'custom' with some: 'override'

This sort of syntax would provide both simplicity and flexibility, allowing for often-used attribute sets to be controlled centrally, while maintaining the liberty of defining specific values for a single instance.

Overall, the role of module attributes seems rather similar to that fulfilled e.g. by Webpack loaders. This is what the Webpack docs say on this now, based on a few years of experience:

Use module.rules whenever possible, as this will reduce boilerplate in your source code and allow you to debug or locate a loader faster if something goes south.

created time in 2 hours

Pull request review commenttc39/ecma262

Editorial: Make numeric values and operations default to mathematical values

 <h1>Number::exponentiate ( _base_, _exponent_ )</h1>           <p>The abstract operation Number::exponentiate takes arguments _base_ (a Number) and _exponent_ (a Number). It returns an implementation-dependent approximation of the result of raising _base_ to the power _exponent_, subject to the following requirements:</p>           <ul>             <li>If _exponent_ is *NaN*, the result is *NaN*.</li>-            <li>If _exponent_ is *+0*, the result is 1, even if _base_ is *NaN*.</li>-            <li>If _exponent_ is *-0*, the result is 1, even if _base_ is *NaN*.</li>+            <li>If _exponent_ is *+0*, the result is *1*<sub>𝔽</sub>, even if _base_ is *NaN*.</li>

I think we need to reach a consensus here. It is clashing with @michaelficarra's previous request to remove subscripts for +0 and -0. I don't have a strong opinion about it and I'm fine with both directions, but it would be good to have a clear path to follow.

caiolima

comment created time in 2 hours

issue openedtc39/proposal-intl-datetime-style

Date-time field widths not set for PartitionDateTimePattern

DateTimeStylePattern only returns a pattern string, let's say for dateStyle the string "{day}.{month}.{year}". When this pattern string is processed in 13.1.6 PartitionDateTimePattern:

Let f be the value of dateTimeFormat's internal slot whose name is the Internal Slot column of the matching row.

We hit a problem, because the internal slots were never set in InitializeDateTimeFormat, so they still default to undefined.

Three things to fix:

created time in 2 hours

Pull request review commenttc39/ecma262

Editorial: Make numeric values and operations default to mathematical values

 <h1>[[DefineOwnProperty]] ( _P_, _Desc_ )</h1>        <emu-clause id="sec-arraycreate" aoid="ArrayCreate">         <h1>ArrayCreate ( _length_ [ , _proto_ ] )</h1>-        <p>The abstract operation ArrayCreate takes argument _length_ (a non-negative integer) and optional argument _proto_. It is used to specify the creation of new Array exotic objects. It performs the following steps when called:</p>+        <p>The abstract operation ArrayCreate takes argument _length_ (a non-negative integral Number) and optional argument _proto_. It is used to specify the creation of new Array exotic objects. It performs the following steps when called:</p>

We need to define it, as we are doing for integral Number. Would it be a problem if we define that non-negative integral Number is integral Numbers greater than +0, considering that +0 is greater than -0?

caiolima

comment created time in 2 hours

issue commenttc39/proposal-intl-DateTimeFormat-formatRange

PartitionDateTimeRangePattern may need additional date-time fields not present in the formatter

Hmm, ICU-based implementations can't even guarantee that the interval and non-interval string use the same output format for date-time fields:

js> var dtf = new Intl.DateTimeFormat("en", {day: "2-digit", timeZone: "UTC"})  
js> dtf.format(0)                                                   
"01"
js> dtf.formatRange(0, 24*60*60*1000)                                          
"1 \u2013 2"

2-digit is only used for the non-interval string, whereas the interval string uses numeric.

So, if we want to specify what's currently implementable using ICU, we need to allow to use different formats for the individual date-time components, which is possible with the proposal outlined in https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/issues/21#issuecomment-634630982.

anba

comment created time in 2 hours

Pull request review commenttc39/ecma262

Editorial: Make numeric values and operations default to mathematical values

 <h1>Data Blocks</h1>        <emu-clause id="sec-createbytedatablock" aoid="CreateByteDataBlock">         <h1>CreateByteDataBlock ( _size_ )</h1>-        <p>The abstract operation CreateByteDataBlock takes argument _size_ (an integer). It performs the following steps when called:</p>+        <p>The abstract operation CreateByteDataBlock takes argument _size_ (an integral Number). It performs the following steps when called:</p>         <emu-alg>-          1. Assert: _size_ &ge; 0.+          1. Assert: _size_ &ge; *+0*.           1. Let _db_ be a new Data Block value consisting of _size_ bytes. If it is impossible to create such a Data Block, throw a *RangeError* exception.-          1. Set all of the bytes of _db_ to 0.+          1. Set all of the bytes of _db_ to *+0*.

I think we need to reach a consensus here. It is clashing with @michaelficarra's previous request to remove subscripts for *+0* and *-0*. I don't have a strong opinion about it and I'm fine with both directions, but it would be good to have a clear path to follow.

caiolima

comment created time in 3 hours

issue commenttc39/proposal-record-tuple

Names of `Tuple.prototype.*` methods

Let's continue discussing this, trying out code in the playground, and be open to revisiting names until Stage 3.

rauschma

comment created time in 3 hours

pull request commenttc39/ecma262

Editorial: Make numeric values and operations default to mathematical values

Thank you very much for the reviews so far. I'm going to keep addressing them in the coming days.

  • I like the use of ℝ(x) as a coercion operator to mathematical values. I don't think we should use ℝ as a subscript to indicate integers or real numbers; instead, those should have no suffix.

That's the intention, but IIUC from your comment, you would like to don't define subscript ℝ? From the changes I've done so far, I agree that they won't be necessary.

  • Having generic operations other than the simplest such as abs() across Numbers and real numbers doesn't work because of various Number glitches (±0, ±∞, NaN, rounding, etc.). We should define those only on real numbers and call utility functions if they're needed on Numbers.

I think I see your point here. So far I've been using Number operations like min or max considering semantics of Math.min and Math.max, but it is not quite correct, since we don't have special cases for (±0, ±∞, NaN) on those generic operations AFICT.

  • There are more places in the algorithms where keeping integral Number counters causes problems if they ever exceed 253. I commented on one example, but there are more and I haven't done an exhaustive pass to find them all. I consider uses of integral Numbers for spec-internal counters suspicious unless proven otherwise.

Those are indeed bugs and thank you for bringing this. I changed a bunch of them, but I'm quite sure that there are leftovers like the one you found.

caiolima

comment created time in 3 hours

issue commenttc39/proposal-intl-DateTimeFormat-formatRange

PartitionDateTimeRangePattern may need additional date-time fields not present in the formatter

Or instead of a whole new separate Intl.DateTimeFormat instance, give the [[rangePatterns]] elements additional fields to define the date-time formats used within the ranges.

For example instead of the current:

[[rangePatterns]]:
    [[Hour]]:
        {[[Source]]: "startRange", [[Pattern]]: "{day}/{month}/{year}, {hour}:{minute}"}
        {[[Source]]: "shared", [[Pattern]]: " – "}
        {[[Source]]: "endRange", [[Pattern]]: "{hour}:{minute}"}
[...]

define it as

[[rangePatterns]]:
    [[Hour]]:
        [[day]]: "numeric"
        [[month]]: "numeric"
        [[year]]: "numeric"
        [[hour]]: "numeric"
        [[minute]]: "2-digit"
        {[[Source]]: "startRange", [[Pattern]]: "{day}/{month}/{year}, {hour}:{minute}"}
        {[[Source]]: "shared", [[Pattern]]: " – "}
        {[[Source]]: "endRange", [[Pattern]]: "{hour}:{minute}"}
[...]

and then use the additional fields within FormatDateTimePattern.

anba

comment created time in 3 hours

startedtc39/proposal-cancellation

started time in 3 hours

issue commenttc39/proposal-record-tuple

Names of `Tuple.prototype.*` methods

I also feel the current names are slightly confusing, but I don't have a better suggestion for now anyway.

rauschma

comment created time in 3 hours

startedtc39/proposal-record-tuple

started time in 3 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

@erights Please take a look at this question in stack overflow: https://softwareengineering.stackexchange.com/questions/280648/why-is-negative-zero-important (in particular, the accepted answer)

bakkot

comment created time in 3 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

The code is sloppy, but doesn't deserve to become bugged.

@kfdf I disagree. Although this code not being bugged would be good on its own, that would be against many other issues I and others have raised. And since one sloppy code is much more fixable and understandable behavior, I believe your example code being bugged is a completely acceptable "price to pay".

bakkot

comment created time in 3 hours

startedtc39/proposal-record-tuple

started time in 3 hours

issue commenttc39/proposal-record-tuple

Equality semantics for `-0` and `NaN`

Thank you @Zarel for creating yet another example of how normalizing is bad!! @icefoxen also made a good job explaining/defending some of these reasons.

I would like to reiterate: IEEE754 has good reasons to do what they did. And even if you happen to disagree with that, """"fixing"""" it in only a specific part of the language will create a huge mess.

Imagine people refactoring all their objects into Records? If -0 is normalized to 0, then they won't, because they just can't.

bakkot

comment created time in 3 hours

more