Discuss
  • Sept 23 2014 Meeting Notes

Sept 23 2014 Meeting Notes

# Rick Waldron (10 years ago)

September 23 2014 Meeting Notes

Brian Terlson (BT), Allen Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo (EF), Jeff Morrison (JM), Jonathan Turner (JT), Sebastian Markbage (SM), Istvan Sebestyen (phone) (IS), Erik Arvidsson (EA), Brendan Eich (BE), Domenic Denicola (DD), Peter Jensen (PJ), Eric Toth (ET), Yehuda Katz (YK), Dave Herman (DH), Brendan Eich (BE), Simon Kaegi (SK), Boris Zbarsky (BZ), Andreas Rossberg (ARB), Caridy Patino (CP), Niko Matsakis (NM), Mark Miller (MM), Matt Miller (MMR), Jaswanth Sreeram (JS)

Introduction

RW: (explanation of evening meetup)

TC39 expresses its appreciate to Bocoup for hosting and ECMA for dinner.

JN: Adoption of agenda?

Approved: tc39/agendas/blob/master/2014/09.md

JN: Approval of minutes (July 2014)

Conclusion/Resolution

  • Agenda approved
  • Previous Minutes approved.`

4.1 Spec status report

(Allen Wirfs-Brock)

Rev27meeting_review.pdf

AWB:

  • Added %IteratorPrototype% that all built-in iterators inherit from.

Issue:

Should %IteratorPrototype% define an @@iterator method?

  • Definition: return this value
  • Currently defined in %GeneratorPrototype% and in the prototype for all built-in iterators.
  • ecmascript#3104

DD: This supports the established convention

YK: There was objection from Jafar DH: but that was to iterator as self-iterable in whole, not this Iterator.prototype which we want

AWB: (summary in slides)

  • Destructuring performs ToObject
  • Array and generator comprehensions removed
  • Realm removed
  • Revised @@unscopable
  • Object.assign ignores null and undefined sources
  • An error to reentrantly enter generator via next/throw/return
  • String(sym) now returns the symbol's description. Does not change ToString(symbol) throwing
  • sym === Object(sym) is now true
  • Tighten specification for when Array.prototype.sort is undefined

AWB: Things being removed should be added to tc39/ecma262

EA: @@unscopables shipping in v8 (needed for Array.prototype.values)

AWB:

  • Added 16.1 that lists forbidden extensions
  • Discussion
  • Removed all explicit poison pill methods on functions (except Function.prototype)

16.1 Forbidden Extensions

AWB: Mark's concern was stack walking capabilities

DH: At odds with proper tail calls

AWB: In ES5 we added things to spec PTC

YK: Of note: the new JDK's JavaScript engine is claiming to be "spec compliant", but implements racy threads.

DH: Most of the algorithms will fall down because they're not designed for threaded environments

Should Ecma-262 section 16 say something about cases like this?

AWB: We can express the "intent", that these are meant to be run atomically

DH: Memory models are hard.

ARB: Just say something informally to the effect that all algorithms in this spec are assumed to be executed atomically, i.e., are never observably interleaved with, or concurrent with, any other mutation of the programs state.

ARB: What specifically does "Extensions" refer to?

AWB: Specifically the definition in 16, bullet 2.

AWB: w/r to Mark's concerns, we may want to specifically say that we don't want implementors to implement stack walking outside of devtools.

AWB: Open work items:

  • Update Introduction (BE)
  • Update Language Overview (RW)
  • RegExp normative and Annex B issues
  • Lexical Grammar may need work
  • Annex B spec for HTML style <!-- --> comments
  • Module spec work closing in
  • Instantiation reform, language + built-ins

AWB: Is anyone interesting in analysing the changes in ES5 to determine things that may have been wrong and need to be rolled back?

RW: Should reach out to Matthias Bynens

AWB: Ideally someone willing to become fully aware of the issues and propose/execute on solutions (if necessary)

AWB: Outline of final spec review process from January through June.

JN: Confirm RFTG opt-out

RW: rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#rftg-admin-es6-opt-out-period

Conclusion/Resolution

  • Add Symbol.iterator on the %IteratorPrototype% that returns this.
  • Due for November meeting
  • Language Overview draft (RW)
  • Introduction (BE)

4.3 Legacy Decimal Integer Literals starting with 0 and containing 8 or

(Allen Wirfs-Brock, Jason Orendorff, Boris Zbarsky)

esdiscuss.org/topic/early-error-on-0-followed-by-8-or-9-in-numeric-literals-does-not-seem-to-be-web-compatible

AWB: Octals beginning with 0 are restricted in strict mode

BZ: Credit card and telephone numbers

AWB: Dates

AWB: In non-strict, where 0 normally means an octal, unless it contains an 8 or 9.

MM: Any program that relies on this will break

> 055

45
> 089

89
> 051082

51082
> (051082).toString()
"51082"
> (051078).toString()
"51078"
> (051077).toString()
"21055"

(Discussion about use of broken features)

MM: Want to preserve the restriction as currently written in strict mode. Strict mode program, testing during August, evals 08 will pass, in January it will not.

AWB: Any browser incompatibilities?

BZ: Anyone writing strict mode code won't be writing code like this. For strict mode there is no hazard.

AWB: For Annex B?

BZ: Pull

MM: All strict mode behaviour is normative

AWB: + Annex B

Discussion re: EscapeCharacter

ecmascript#3212

BE: It was changed in ES3 to use DecimalDigit (from ES1's OctalDigit), would need to ask Waldemar

Conclusion/Resolution

  • Leave strict mode as-is
  • Disallow leading zeroes, except for the constant 0 (and 0.1234 etc)
  • Annex B non-strict: explicitly define the current interoperable behavior
  • \8 and \9 are equivalent to literal 8 and 9
  • '\08' is NUL char and then '8', '\08'.length is 2

4.4 Number('0b0101'). NaN or not?

(Erik Arvidsson)

EA: Previous discussion: rwaldron/tc39-notes/blob/c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2014-04/apr-9.md#46-updates-to-parseint

Should Number be able to parse the string "0b0" or "0o1"

(Discussion of people (ab)using Number for converting user input and whether this should affect things.)

Yes.

Conclusion/Resolution

  • Use spec-internal ToNumber via userland Number called as a function will convert (ie Number('0b101') === 5).
  • Upholding previous consensus on parseInt
  • Note in Annex C that this extension is a potentially breaking change

4.5 More Function-in-Block

(Brian Terlson)

BT: (covers current spec)

AWB: Exactly the strict modes semantics of functions in blocks

BT: Don't hoist past/up-to nearest function

New issue:

if (cond) {
  function F() {}
  function G() { F() }
}

// sometime later
if (cond) {
  function F() {}
}

G();

In today's semantics, when G(); is called, it calls the second F();. In the new design, it would be the first, which is a breaking change. This code actually exists in some ad code somewhere.

BT: No one else has implemented this yet, need to know if IE will be out there alone, or will other browsers stand with IE and break that unusual ad code?

DH: If v8 and spidermonkey post bugs that indicate the intention to implement, then it shows support among implementors and is valuable.

Conclusion/Resolution

Intro to Matt Miller from IETF (Liaison manager)

MMR: (Role as liaison from IETF, to establish a productive relationship, specifically w/r to JSON)

AWB: IETF Documents, eg. JavaScript mimetype references to ES3. Far behind considering ES5 and soon ES6

MMR: The RFCs are stable documents. When a document receives a number, it's set. If it needs to be updated, it can be replaced.

Discussion about interoperability and incompatibility breaks.

Conclusion/Resolution

  • Improved communication

Revisiting 16.1, Forbidden Extensions

MM: SpiderMonkey removed own caller and own arguments from all function forms ... Needs to be clear: if the this binding is strict or built-in.

AWB: interpret: If it isn't a non-strict function, it behaves exactly as spec'ed.

Discussion of strict/non-strict w/r to built-ins

MM: Applied to anything other than a non-strict function?

(10 minute back and forth about the definitions of "strict function" and "ECMAScript function")

MM's overall concern is to make sure the behavior is nailed down for built-ins as well as for strict functions.

Somehow we started talking about test262

Discussion of test262's (lack of) coverage.

BT: We didn't have coverage in test262 of a non-enumerable property shadowing an enumerable property.

JM: it would be good to have a place to list the open coverage holes.

SK/DD: while reviewing sections of the spec, people should write down a list of test cases that should be written (e.g. domenic/Array.prototype.contains#1 )

AWB: Perhaps we should try to get a rough statement of what our coverage areas are. Some areas are covered because they were in ES3 tests; Microsoft contributed a lot of standard library tests; there are probably lots of gaps.

(Discussion of running test262 tests against implementations, especially given their optimizations.)

YK: ideally we should not run the tests in interpreted mode.

AR: there is no hot code in test262, so right now we only run in interpreted mode.

YK: could we use switches to turn up optimizations?

AR: there are complications that in V8 at least make that unlikely to be useful.

(Back to topic of a statement of coverage)

AWB: I'm mostly interested in whether there is a useful set of tests for most areas of the spec

BT: was this the test262 agenda item?

BE: this was the "depress the room" agenda item

DD/BT: (discussion of poisoning built-ins before running tests)

YK: Value of poisioning?

BT: Implementations have to take care to not rely on user modifiable built-ins.

  • Test262 attempts to walk a balance, if there are known examples that break runtime, there will be tests, but we don't go looking for them.

Conclusion/Resolution

  • It's impossible to test ECMAScript
  • Testing is hard

Test 262 Update

(Brian Terlson)

BT: A number of PRs remain open from the Test The Web Forward event: people haven't signed CLA despite request, haven't updated patch according to review feedback. These will be closed.

  • Browser will currently hang on 2**32 ToLength tests; these are initializing and iterating
  • Previous consensus was to not update test262 on ecmascript.org. Any objections to creating a preview of ES6 test262?
  • extracted test runner harness, wip.
  • Suggest transferring test harness to ecma

DD: Have two official runners?

DD/BT: Deprecating the python runner?

ARB: Have to check with testing infrastructure

DD: But can we "deprecate", in the

  • Repository organization?

BT: Move all tests from present locations to new homes in new directory heirarchy

  • someone, or something, needs to move 11,500 tests from their current location to their new location
  • Leave all ES5 where they are?
  • Create new tests under named feature.

AWB: As tests are updated, they could be moved?

BT: confirm

BT: who moved the ES3 tests to ES5 organization?

MM: that was me

BT: that was fun?

MM: I have experienced traumas in my life that were less fun

(Discussion of whether we should move the ES5 stuff piecemeal, e.g. as they get fixed.)

BT: It might be OK to move by feature, e.g. all the Array.prototype.forEach tests could move at once.

(Discussion of how to incorporate post-ES6 tests into the repo, as they are written, but before ES6 tests are finalized.)

AWB: when running "the ES6 test suite," it should only be things that are officially in ES6. But the JS community cares about what they can use in a browser. We should not create impressions that things are done or stable until they have worked through the process.

AR: so we should put experimental things into a separate directory

YK: no. You don't do that in Chrome; you use feature flags.

(Discussion of folder vs. feature flags for new test262 tests for post-ES6 experimental features.)

AWB: ok with stage 3 being in the repo

DD: needs to be stage 1 and onward

AWB: At stage 1, it's just the champion

BT: Prerequisite to stage 3: have a PR open with your test

DD: Just need a way to flag something as experimental

BT: Accept Allen's proposal?

DD/YK: nooooo

ARB: Fine to have early stage features, as long as they're not intermingled.

BT: The file system isn't ideal.

(Discussion of whether to accept stage 1 onward into test262.)

DD: Want to make test262 writing easy, so will be adding helpers.

Conclusion/Resolution

  • Create a subdomain to host test262's ES6 tests
  • Deprecation plan for Python harness: contact
  • Domenic or Andreas for V8
  • Dave for SpiderMonkey
  • Overturn previous consensus, leave ES5 tests where they are.
  • Let Brian decide which features to pull in
  • Stage 3 features (and onward) shows up on the experimental public site
  • Add helpers, that's good.

5.1 Trailing Commas in Function Call Expressions and Declarations

(Jeff Morrison)

JM: Useful for diffs in version control systems, especially Git blame. In other languages they often do a comma at the end of each line. We do for commas too.

BE: arrays aren't parameter lists. What other languages allow this?

JM: Python, D, Hack, probably others

JM: you don't have to do this if you don't want to; it's easy to lint for...

MM: just use comma-first style?

JM: doesn't work well for the first argument

AWB: What about rest parameter position? Should it be a syntax error after a rest param?

JM: Hadn't thought about it. No strong feelings. Makes sense to me to be invalid after a trailing rest param

function f(
a,
b,
...c
    ) {
return 1;
}

MM: what's the argument against this?

JM: if people use this, old engines won't be able to run that code.

AWB: it's the "no new syntax" argument.

BE: the funny thing is in C you can't have enums with trailing commas but you can have them in array and struct initializers. That was a botch.

Conclusion/Resolution

BE: let's sleep on it

  • No decision yet, revisit tomorrow.

?.? Process

AWB: When something reaches stage 1 we should create a repo at TC39. And use that issue tracker for discussion instead of es-discuss or bugs.ecmascript.org or other ad-hoc locations.

5.2 Flush denorm to zero

(Allen Wirfs-Brock)

esdiscuss.org/topic/float-denormal-issue-in-javascript-processor-node-in-web-audio-api, bugzilla.mozilla.org/show_bug.cgi?id=1027624#c30

AWB/BE: Explanation of "flush to denorm"

en.wikipedia.org/wiki/Denormal_number

Denorm values appear in audio algorithms. Modes exist to prevent producing denorms.

MM: Not just wasted precision:

|-|-|-|-------|-------|-|-|-|
      ^       0       ^
largest               smallest
negative              positive
normal                normal

AWB: Specifically desirable from people writing audio algorithms in JavaScript.

BE:

Math.denormz(x);
Math.fdenormz(x);

Math.fdenormz(x) === Math.denormz(Math.fround(x));

PJ: Another suggestion to have an FPU mode-setting function?

BE/AWB: That's the big red switch.

BE: Leads to all black-box/other-module functions needing save/restore advice around calls from your module

  • Stage 1?

Conclusion/Resolution

  • Stage 1

5.3 ArrayBuffer.transfer

(Brendan Eich, Allen Wirfs-Brock for Luke Wagner)

gist.github.com/andhow/95fb9e49996615764eff

AWB: (summarizes rationale)

(Discussion re detaching, immutability, freezing, and how they may or may not be related)

BE: ArrayBuffer.transfer seems safe, considering.

Discussion of whether it should be static on ArrayBuffer or a method on the prototype - it's an alternative constructor

Suggestion that ArrayBuffer.transfer(b1, 0) return a zero-length b2, not null. Consensus favors.

AWB: Subclass of ArrayBuffer? What is the class of the object returned by transfer(...)?

Conclusion/Resolution

  • Stage 1

5.6 NoSuchProperty built-in proxy

(Brendan Eich for Nicholas C. Zakas)

BE: Want to be able to throw if a property access occurs for something that doesn't exist.

var NoSuchProperty = Proxy({}, {
  has(target, name) {
   return true;
  },
  get(target, name, receiver) {
    if (name in Object.prototype) {
      return Object.prototype[name];
    }
    throw new TypeError(name + " is not a defined property");
  }
});

BE: JS1 was a rush, didn't have time for try/catch, so I was very shy about errors. This should be something that can be made an error. Too much fail-soft where things should've error'ed.

MM: If it's doable in library code, then we should wait until we see more activity.

YK/DD/RW: There are more Proxy related patterns that would more valuable to address before NoSuchProperty, considering it's possible in library code.

DH: (comments on likelihood of actual use)

BE: This will be slow

BZ: It will be fine until you hit the Proxy, based on real engine DOM (nodelist etc.) experience.

Conclusion/Resolution

  • Keep in library code which others should develop and user-test at scale

5.8 Exponentiation Operator Update

(Rick Waldron)

RW: Presenting updates to feature proposal:

Progress to Stage 2?

Confirm.

Conclusion/Resolution

  • Stage 2

5.5 Math.iaddh, etc. polyfillable 64-bit int helpers

(Brendan Eich for Fabrice Bellard)

esdiscuss.org/topic/efficient-64-bit-arithmetic, gist.github.com/BrendanEich/4294d5c212a6d2254703

MM: Recognizes "bigit" as good for bignum big decimal etc. digit, not just for int64 emu

( hackage.haskell.org/package/double-conversion-0.2.0.6/src/double-conversion/src/bignum.cc, code.ohloh.net/file?fid=J9lbBTlP__EhaF2Zrwq6Sk38lZE&cid=891oM4GeZTE&s=&fp=282835&mp&projSelected=true#L0 )

Concrete proposal:

Math.imulh();
Math.imuluh();
Math.iaddh();
Math.isubh();

Conclusion/Resolution

  • Rename imuluh to umulh
  • Stage 0
# Mathias Bynens (10 years ago)

Thanks for once again putting this together, Rick!

On Fri, Oct 3, 2014 at 3:22 PM, Rick Waldron <waldron.rick at gmail.com> wrote:

4.4 Number('0b0101'). NaN or not?

(Erik Arvidsson)

EA: Previous discussion: rwaldron/tc39-notes/blob/c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2014-04/apr-9.md#46-updates-to-parseint

Should Number be able to parse the string "0b0" or "0o1"

(Discussion of people (ab)using Number for converting user input and whether this should affect things.)

Yes.

Conclusion/Resolution

  • Use spec-internal ToNumber via userland Number called as a function will convert (ie Number('0b101') === 5).
  • Upholding previous consensus on parseInt

I don’t understand this reasoning. Making parseInt understand the new syntax was considered a security hazard, but for Number we can somehow get away with it? Any more information on the disconnect?

# Erik Arvidsson (10 years ago)

Number has always been able to handle the full NumericLiteral. In ES5.1 it can handle '-1', '-0', '0xff', '0XFF', '1e2', '-1E-2', 'Infinity'. Breaking that consistency was unwanted.

This means that it is a change to existing semantics. We think we can get away with it though.

  • ES5.1: Number('0b10') === NaN
  • ES6: Number('0b10') === 2

I don't know why Waldemar thought this would be a security issue for parseInt? I wasn't at that meeting and the notes do not cover that.

# Rick Waldron (10 years ago)

On Fri, Oct 3, 2014 at 10:04 AM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:

I don't know why Waldemar thought this would be a security issue for parseInt? I wasn't at that meeting and the notes do not cover that.

The security concern was for validating user input and any reliance on the existing semantics being broken.

# Allen Wirfs-Brock (10 years ago)

On Oct 3, 2014, at 7:35 AM, Rick Waldron wrote:

The security concern was for validating user input and any reliance on the existing semantics being broken.

parseInt: "parseInt may interpret only a leading portion of string as an integer value; it ignores any code units that cannot be interpreted as part of the notation of an integer, and no indication is given that any such code units were ignored."

  • ES5: parseInt("0b10") //0
  • ES6 as specified: parseInt("0b10") //0
  • ES6 if new forms recognized: parseInt("0b10") //2

Number: "ToNumber applied to Strings applies the following grammar to the input String interpreted as a sequence of UTF-16 encoded code points. If the grammar cannot interpret the String as an expansion of StringNumericLiteral, then the result of ToNumber is NaN."

  • ES5: Number("0b10") //NaN
  • ES6: Number("0b10") //2