April 8 2014 Meeting Notes
Rick Waldron
waldron.rick at gmail.com
Tue Apr 15 07:24:59 PDT 2014
# April 8 2014 Meeting Notes
Doug Crockford (DC), Brian Terleson (BT), Luke Hoban (LH), Dmitry Lomov
(DL), Waldemar Horwat (WH), Allen Wirfs-Brock (AWB), John Neumann (JN),
Rick Hudson (RH), Rick Waldron (RW), Eric Ferraiuolo (EF), Jafar Husain
(JH), Jeff Morrison (JM), Sung-Jae Lee (SJL), Seo-Young Hwang, Mark
Honenberg (MH), Caridy Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM),
Ben Newman (BN), Filip Pizlo (FP), Satish Chondra (SC), Domenic Denicola
(DD), Mark Miller (MM)
## Welcome
JN: (open remarks)
AWB: logistics
## Introductions
See attendee list
## Agenda
https://github.com/tc39/agendas/blob/master/2014/04.md
JN: Agenda approved with changes.
## Minutes
JN: Approval of minutes from Jan 2014, Ecma document 007
## 4.1 Review Latest Spec Draft
(Allen Wirfs-Brock)
Slides: [April-meeting-status-ES6-spec.pdf](
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-04/April-meeting-status-ES6-spec.pdf
)
AWB: Updates to formatting, etc.
Summary of changes:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_23_2013_draft_rev_17
YK: Concerns about let bindings in function parameters
...Let's make sure that anything in ES5 that does not have a let binding
doesn't produce such, to avoid interop hazards.
BT: In IE11, you can't create a let binding whose identifier is the same as
a function parameter
AWB/YK: Then this is a spec bug. (AWB: not clear what this is referring
to, the behavior described above for IE11 sounds correct)
BT: Even `var x; let x;` is an error
AWB: There are lexical bindings that the closure captures and then there
are static semantic rules that say you cannot have a `let` in the body that
are same name as a `parameter`
... We need
LH: `let` is not designed to directly replace `var`, it's a benefit that
these static rules exist.
RW: Agree (`let` is not the new `var`)
AWB: Cannot `import x` and then `let x`, this would be a redeclaration.
...There is an item to discuss `catch(e)`
WH: What are the ContainsExpressions rules in the function declaration
instantiation spec for? As far as I can tell, they're an optimization to
take out an invisible environment. They appear to have no visible effect.
AWB: Yes, that's invisible. Went back and forth about whether to express
such optimizations in the spec.
AWB: (moving on)
- Lookahead grammar restriction created, to disambiguate `new super()`
(AWB: but they aren't right yet. Stills needs some more work)
- Lookahead `let` restrictions added: IterationStatement (see notes)
- Temporary change return default for missing class constructor: Reverted.
AWB: First call to a generator (half of 4.ii on the agenda)
- Eliminate throw if argument is passed
- Argument is ignored and inaccessibe
- Differing recolltions on January discussion
- Most compelling reason: creates unnecessary difference between generator
and manual implementaion of equivalent iterators.
#### 4.2 Conclusion/Resolution
- removal of the thrown exception when a value is passed to next() for a
newborn generator
- further discussion to be had by Ben Newman and Dave Herman re: what to do
with that value.
AWB: (continuing)
```js
Array.from({0: 0, 4:4, length: 5});
```
... didn't produce a sparse array. Changed in Rev23.
Current spec says: in no way can `Array.from` produce a sparse array.
RW: This is good and makes the behaviour consistent with the iterator path
in `Array.from`
YK: Generally, sparse arrays are dead.
(no opposition)
AWB: (continuing) Corrected RegExpExec so it correcly translates the match
state of full unicode RegExps back to UTF-16 cature values and endIndex
WH: If you have a composed character, is it still considered two characters?
AWB: Yes, it operates at the level of code points or code units. Not a
higher livel such as composed characters
YK: (requesting more information about the the ES5 compatibility change
item added to Annex D)
RW: (note: it appears to be missing, Allen, please fill in/follow up?)
AWB: Call for Spec reviewers
BT: Need to create a "sign up" for task assignment for reviewing sections
AWB: Would like to see two TC39 members reviewing each of the sections
... September is the _end_, otherwise we risk delaying for another 6
months. The final reviewing needs to be done between now and July.
MM: Last meeting I said I was going to organize a security review. There
are no draft implementations of the Realm API which will make the
exploratory process of analyzing the system useless. There has to be some
time to poke at a draft implementation before committing.
YK: We should wait to delve into this issue (modules) with Dave present
AWB: Agreed
MM: Putting the Realm aside, I have no concerns for the modules
specification
JM: What exactly is missing, what can we work on to help make progress.
LH: What about the JS Loader projects that exist?
YK: There is no way to do the Realm API with those, however the Loader
implementations
JM: Can `contextify` be used to implement Realm?
MM: There may be way to use this to discover holes. Let's take a look at
it. There may be a way to expose issues in the same way.
AWB: There are changes to the Realm API, since the last meeting.
LH: Are there further expected changes?
AWB: One of the issues is the eval support is now at the Realm level. One
of the change we got down from 4 methods to three methods re: eval.
YK: We should avoid discussing this without Dave present?
LH: There are API changes expected in Realms? Are there API changes in
Loader?
AWB: Hopefully
LH: That's what expected
YK: Special casing class and function to create bindings at the parent
level for `export default function foo` and `export default class foo`. We
should special case those expression forms to behave like declaration forms
LH/BT: Yes.
AWB: If you want to treat it like an expression, put it in parens.
WH: What is `export default`?
YK: We've discussed this
AWB: (recapping the utility and specification of default exports)
WH: Can only have one default?
AWB/YK: Yes.
AWB: It's for modules that you want to export without a specific name.
YK: Compatibility with a desirable style of programming.
LH: We need to lock down API changes as soon as possible.
YK: It's possible to punt on Realm API (to ES7). Dave specifically designed
this to separable.
MM: Where would you draw the line? If Realms were on the opposite side of
the line, where would you draw the line?
AWB: I could draw a line: No API.
YK: Draw a line? No public Realm API, but the semeantics are still there.
LH: Our success critically relies on Loader API, this is where requirements
are resolved.
...Discussion about Loader API
LH: All of the multiple phase complexity is needed
Discussion about Guy Bedford's work, es6-module-transpiler, traceur, etc.
YK: I'll open discussion with Guy to pinpoint hardships in implementation
LH: This will be helpful
EF: (to Brian) you're presenting implementation report?
BT: No, just feedback from TypeScript
### Open Issues
AWB: for of/in, initialization expression scoping?
```
{
let x = [0, 1];
for (let x of x) console.log(x);
}
```
WH: Wouldn't it be the same as saying `let x = x`?
AWB: should be
- Current spec: of/in expression evaluated in enclosing scope:. Log: 0 1
- Possible alternative: extra scope with uninitialized x. Throws TDZ error
LH: This example has two scopes, the alternative has three?
...for creates a scope
...Why do you want to change?
AWB: There have been arguments that say `x` isn't yet initialized in the
`for` scope
WH: Is the question: creating the scope before or after?
AWB: We have to create an extra scope where `x` is dead.
(ah-ha moment.)
AWB: Need input from implementors
MM: If no one has a strong reason, I suggest going through the second
approach.
YK: err on the side of being more useful to the programmer
MM/AWB: Yes
WH: There might not be a dead zone violation
MM: it would be a dead zone violation in the second bullet
... There is only no dead zone violation if you don't touch it.
AWB: We need a consistent approach
... Already have this extra scope
AWB: Need to go back, we may initialize that outer binding and maybe we
shouldn't
#### Conclusion/Resolution
- Be consistent
- Look at the initialization scope and be sure to intentionally _never_
initialize the for bindings in that scope
- Solution to open issue: extra scope with uninitialized x. Throws TDZ error
### var hoisting and catch parameters
AWB:
```js
catch (x) {
var x = 42;
}
```
Discussion about the existance of this code in real world.
BT: This exists in code found in the top 1k sites
AWB: i can remove the static semantics rule that's specifiically for catch,
that says this is an error. In that case, it will be just like ES5, there
will be a var and the var will be hoisted. Need to look at various place
where simplifications of runtime semantics that assume this has been
applied.
YK: Question about the actual binding.
WH: The same that happens inside a `with` that has captures a property with
the same name as a var—the var hoists out.
YK: What is the negative effect of creating a binding that's undefined?
...Change incompatibility should have a higher bar than "it complicates the
spec"
MM: Breaking changes aren't worth
WH: Keep the catch as a `let` binding, but make it not an error in Annex B,
just for catch (not for let's in general)
LH/AWB: I like this
FP: It seems better to keep the existing behaviour?
MM: Is Annex B, normative? Normative optional?
YK: Confirms that Annex B is _required_ for browsers but normative/optional
for non browsers
MM: Ok, no issue then.
Agreement that browser implementation will lead and others will follow for
compatibility.
YK: Also need to make sure that this is not an error:
```js
catch(x) {
function x() {
}
}
```
AWB: This is an error
WH: Any reason for us to believe this exists in the wild?
BT: Looked for this pattern, with no findings, but absence in top 1k
doesn't mean non-existence.
WH: Disallow this and see if there is any pushback.
#### Conclusion/Resolution
- Keep the catch as a `let` binding, but make it not an error in Annex B,
just for `catch` (no other)
- If redeclaration with `let` or `const` is still a redeclaration error
(this is no change)
- Continue to disallow function declaration in catch
MM: This could only exist in non-strict code.
YK: The same behaviour as:
```js
{
let x;
let x;
function x() {}
}
```
Confirm.
## Presentation by Samsung Representatives
Slides: [ecma-tc39-talk-v1.0.pdf](
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-04/ecma-tc39-talk-v1.0.pdf
)
Presentation focus on intent of committee participation
- JS on wearable devices
- JS on microcontrollers (small memory devices)
Interested in building a small footprint JS engine
- Wearables and IoT
- A subset?
- Possibly as an open source project
We are here to ask your opinion about approach
- multi level subset of profile of ECMAScript
- is it reasonable to define a subset
- can this be covered can this committee
WH: 48K of RAM? That's the same as an Apple II.
WH: Just supporting Unicode takes a lot more memory than that.
MM: What about running existing code?
RW: (share experience of using JS subset in microcontroller environments)
SC: (more about goals of the platform, re: HTML/CSS)
LH: HTML and CSS are massive
RW: Platform dependencies themselves assume specification compliance
WH: One of the reasons for selecting a subset of JavaScript is that you can
write applications for the device that also run in the browser.
WH: While libraries are big, a subset of the "good parts" of ECMAScript
would also be useful for reducing memory usage.
?: How so?
WH: Some of the features of ECMAScript (such as peculiarities of eval)
pretty much require efficient implementations to do speculative
optimization and then have a mapping and a way to back out if the
assumptions fail. That mapping and the extra copy of the code for
deoptimization costs memory.
YK: So don't optimize. Use an interpreter.
WH: Lack of optimization would waste battery power on small devices.
RH: points about starting and reducing
LH: It's important to consider what are you willing to trade?
Mixed discussion about ES versions that might be considered subsets
themselves.
AWB: There is clearly concern here, but it would be valuable to have you
included and there are people here that are interested in small device
platforms.
## [[SetPrototypeOf]] circularity invariant
(Allen Wirfs-Brock)
- If Proxy involved, impossible to enforce on prototype chain
- Eliminate the invariant?
- Is there some weaker invalriant we might replace with?
LH: How?
AWB: getPrototypeOf can lie while the invariant is being checked
MM: Are there any recommendations beyond dropping the invariant?
FP: (Question about requirements)
MM: Any defensible options other than dropping the invariant?
AWB: No
WH: Yes. To prevent proxy cycles, something in the proxy (perhaps the
target's prototype, perhaps something else) would record what the proxy
thinks the prototype is. GetPrototypeOf does not run user code and only
returns the current stored value. SetPrototypeOf runs user code and can
change the stored value. The circularity check occurs at the time of the
store.
AWB: Possible for ordinary objects, if the prototype chain only consists of
ordinary objects, there must not be circularities.
Discussion about Proxy trap handlers for `getPrototypeOf` and
`setPrototypeOf`
MM: Storing state related to the target
BN: In the same way there is RangeError for call recursion, is there a way
to RangeError on length of prototype walk
MM: Waldemar's rule will give you the error earlier.
WH: It's better to pay the runtime cost in the less frequent cases that
change prototypes rather than having to pay it every time a prototype chain
is read.
NM: The more user code we can get out of the prototype look up, the better.
AWB: Ask Tom about intervening when user sets prototype
YK/MM: Agree.
#### Conclusion/Resolution
- Prevent proxy cycles. If the target is a proxy, the proxy target
prototype records what it thinks the proxy prototype is, and returns the
targets protototype and setPrototype is never called
- Whenever you change a prototype, you run a circulartity check immediately.
(the following is about whether [[SetPrototypeOf]] should be allowed modify
the prototype of Object.prototype)
BT: Does the proxy's handler have get trap
WH: If it does, there is an infinite loop
MM: Even without Object.prototype, you can create this same loop
- When you mess around with prototypes, you can render the entire
environment inoperable.
BT: Setting Object.prototype to a Proxy?
WH: I agree with you but not worried about it.
YK: Proxy is the only way to implement exotic behaviour in user code.
MM: Too late to draw the line about what prototypes can be assigned a Proxy.
(This addressed agenda item 4.9)
## Promise then issue
```js
p.then(42, "43")
.then(false, new Map);
```
- Error or default argument values if actual argument is not callable?
- if error throw or asynch error?
AWB: Area of disagreement that Andreas brought up:
- The arguments to then are supposed to be functions,
- If the first argument isn't provided and not explicitly `undefined` or
`null`,
What do you do with non-callable arguments?
Possible solutions:
- The same thing if you provide no argument?
- Throw?
Currently throws.
LH: The current behaviour is throw
MM: Domenic wants it to not indicate an error?
AWB: Correct.
Here's an example:
```js
p.then(expr && callable);
```
If `expr` evaluates to false, this non-callable false value is passed.
AWB: The claim is that all libraries accept the non-callable and just use
the default.
JH, WH: Do we unwrap eagerly or lazily?
AWB: We'll get to that issue.
LH: WinJS throws
JH: (jafar, this point was about sync and async errors, can you fill in?)
YK: (points about errors that are logged to the console)
Discussion about IDL
YK: There are two development modes, one that wants all errors logged and
one that does not.
WH: Don't want some errors sync and some errors async
(Note: the point of this discussion is whether `p.then(non-callable)`
should throw synchronously)
AWB reviews spec and finds other points in which then throws synchronously
LH: Where do you draw the line that differentiates what is a runtime error
and a construction time error
JH: Why make a distinction?
LH: Right, it's very difficult and causes you to be very specific. Or just
"give up"
AWB: Don't type check unless you need to
LH: The spec always does type checking up front, for example
`[].map(null)`, this throws.
RW: (presents own position which agrees with LH)
(Present Domenic's position verbatim)
DD (via RW):
> Changing these to throws from existing promise code is a refactoring
hazard. Similar to making methods non-enumerable. i'm ok with it rejecting,
but not with it throwing, then you have to do .catch() AND catch { }, it's
still a refactoring hazard, but at least one that doesn't screw you over by
creating sync errors in code that previously only expected async ones.
AWB:
LH: Ok, so Domenic made two points:
- The Refactoring Hazard
- Making it an error means you have to decide whether it's sync or async
LH: 3 options
- Sync error
- Async error
- No Error
YK/RW: Domenic is ok with async error (ie. reject)
JM: If didn't want async error, is there a way to emulate?
No
LH:
JM: Promises exist in two stages: setup stage, execution stage. setup stage
is the code that is written, the execution stage is async behaviour. setup
stage errors should be sync
RW: agree
LH: it should never be required to put a try/catch around `p.then`.
(restates JM)
YK: conflation of two modes
MM: Why is `.then(non-callable)` different then a malformed subclassing?
(the latter is sync)
LH: let's narrow it down and take "no error" off the table.
Agreement.
2 options:
- Sync error
- Async error
LH: IDL currently does all type checks on parameters sync.
YK/LH: If you were to use `await`, always get all of your type checking
inside the async flow.
YK: The way to look at this is to treat it like it's an async function.
(Domenic Denicola call in)
LH: (recap current discussion)
DD: First, strange that we are accepting null, but not false or 0. Why is
null and undefined on one side, but other values on the other. Second, the
refactor hazard.
MM: What does Q do?
DD: If Promise A+ does this and with the amount of code that already relies
on this.
LH: Agree that accepting null and undefined is already
DD: Precendent: IgnoreNonCallable in JSON.parse and JSON.stringify,
.valueOf; Array.prototype.sort throws for non-callable
MM: For sort?
DD: sort throws if you pass non-callable
(AWB: actually ES5 says that sort is implementation defined if argument is
a non-callables other than undefined.)
YK: Enough evidence to leave it as is
LH: I'm convinced.
Discussion about IDL optional function vs. mandatory function
MM: Recalling that originally, no part of Promise.then executed
synchronously.
Case in concern:
```js
Promise.resolve(instanceOfSubclass);
```
DD: returns a `Promise`
MM: How does `Promise.resolve()` handle `instanceOfSubclass`
DD: Treats it as an untrusted thenable
MM: Excellent
Review of `Promise.resolve`, focused on
`Promise.resolve(untrustedObject).then(onFulfilled, onRejected)`
MM: Before subclassing, we had the safety property, given frozen Promise
and Promise.prototype, that
Promise.resolve(untrustedObject).then(...untrustedArguments)
did not run user code synchronously during these two calls. Satisfied that
we have
preserved this safety property.
YK: Enough evidence that we shouldn't error here and then all other errors
are async.
AWB: Anything that's non-callable uses the default (not just null and
undefined)
Discussion about precedent.
WH: Reluctant to go with no error. It's a bad idea to silently ignore
things such as attempts to write read-only variables or call things that
are not functions.
WH: No particular precedent here. Some places throw when you call a
non-function, some don't. If the sort comparator is not undefined and not a
function, the standard throws.
AWB: The presented arguments are 2/3 in JSON functions
LH: Do we want to set a precedent?
...The Loader API throws on non-callable.
MM: Crock, was there a reason you chose not to throw on non-callable?
DC: No particular criteria.
MM: Experience with the API?
DC: I'd be reluctant to do the same again.
The discussion is now:
- Async Error
- No Error
RW: Firefox Nightly doesn't throw on this
DD: Chrome doesn't throw
MM: Given the state, I don't think we should change.
LH: If making a change mattered, then we should make the change. If there
are no benefits, then "do no damage" first.
LH: (discussion about the amount of time we spend on these things)
... p.then(42)? Doesn't matter. It's a minor corner case (we should go with
what programmers expect)
The decision for how to handle this non-callable case could inform all
cases that expect functions
MM/WH: Don't really like the silently tolerant behaviour in general. Want
the general precedent to be to throw errors when calling something that
can't be called, but willing to make an exception in this case due to the
established library usage.
#### Conclusion/Resolution
- w/r to .then, respect libraries: no error.
- do not adopt this as a principle for non-callables passed where callables
are expected, the general principal: if something is neither a callable or
undefined, indicate an error.
DD: Optional callable vs. required callable. There is spec text that
matches neither of the consequents.
?: Example is [].map(nonCallable). If you pre-check, this errors. If you
"just call it", this does not error (since it never gets called.)
MM: Per the principle defined, you'd simply check if the argument is
defined, if it is, call it.
## @@iterator for arguments object
AWB:
- Own Property?
- Or should introduce a prototype object to contain it?
RW: There is a record of an agreement for this from several years ago
BT: Not sure why we want to do this for arguments?
JH: Don't want to encourage programmers to use arguments object in ES6
RW: Agrees, but not sure that's the right way to go.
RW: We already have consensus on iterator protocol for arguments object.
MM: Any notes on own vs prototype?
RW: No.
YK: Foresee a problem
RW: agree that we should do it, purely for consistency, but practioners
need to discourage the use of `arguments` in ES6 code.
AWB: 2 Cases:
- want each by name
- want to parse the arguments list
Discussion about default params pattern and `...arguments` delegation.
Back to consensus on inclusion
MM: Strong against introducing Arguments.prototype
RW: Same.
JH: Ideally the @@iterator is on a prototype to avoid the allocation costs.
YK: Implementations can optimize.
#### Conclusion/Resolution
- @@iterator on arguments object
- specified as an own property (no creation of exposed Arguments.prototype)
- Updated: https://bugs.ecmascript.org/show_bug.cgi?id=1114
## Default parameters
(Brian)
BT:
```js
function f(a = 1) {
console.log(a, arguments[0]); // 1, undefined ?
}
f(undefined);
```
BN: That's consistent with the difference between arguments and parameters.
BT: If a default or rest param, you get non-mapped arguments.
MM: What is arguments.length?
BT: Always based on what is _passed_
RW: There is a rule that was created, which is relevant to this discussion:
https://github.com/rwaldron/tc39-notes/blob/6d88efa7c4eba2d7a8b6fd5801f2415c2f29c94c/es6/2013-07/july-25.md#consensusresolution
MM: Avoidance of micromodes if possible. (Mark, can you fill this in? It
was re: craziness)
#### Conclusion/Resolution
- An argument list that only has identifiers in sloppy mode has mapped
arguments object. ALL other arguments objects (ie. any that contain
default, destructuring, or rest, or those in strict mode) don't map.
## Initializer in for-in
AWB:
```js
for (var x = "nothing" in foo) { ... }
```
Previously convinced that this was safe to remove. Apple implementors
reported breakage caused by removing this.
MH: (confirms) Have encountered sites that have this code.
YK: I understand the desire to clean up, but if clean up causes breakage
then why bother?
AWB: Need to address the let case (AWB: this was more about consistacy with
the let case. let case does not have the initializer but as new syntax that
doesn't introduce any compatability issues.)
YK: Nothing happens in the let case,
MM: Except for the side effects of the expression
AWB: So basically it was a matter of seeing if we can
YK: As a rule, we should err on the side of caution when faced with these
minor changes that create incompatibilities once we find real-world
problems.
#### Conclusion/Resolution
- Punt on a decision until May
## Function "as" Block
BT:
```js
if (true) function f() {
}
```
MM/BT: Already illegal in strict mode
BT: In all browsers, you can call `f()` after this, but doesn't hoist.
WH: That's a contradiction, you said it doesn't hoist but can be called.
(This is the problem?)
BT: On the list, Brendan was opposed to adding this to Annex B
WH: Is this hypothetical or real breakage? Where does this actually occur
in the wild?
BT: ...haven't seen this anywhere in the existing code
WH: Inclined to keep the new semantics simple and ignore this.
MM: Not seeing in the wild? Back off
YK: If we can get implementors to agree to make this an error, then we'll
specify it as such
AWB: note: file bug to have this tested in Firefox
#### Conclusion/Resolution
- Allen will file bug to have this tested in Firefox
## Name property of bound functions and toMethod functions
AWB:
- Currently neither have an own name property
- Should either or both get one?
- If so, what should it be?
- "bound foo"? (for the bound case)
YK: Why this naming?
RW: In the current ES6 specification, for the name property of function,
accessors are prefixed by "get " and "set " (trailing space intended).
AWB: Don't think about these name conventions as any kind of type
information, just as an a means to distinguish
MM: what about toMethod?
AWB: Suggest no qualifier
Reviewing toMethod
MM: What about function properties named "get foo"?
MM: I guess this is ok. These names are not high-integrity -- mostly
intended for debugging info.
#### Conclusion/Resolution
- toMethod: no prefix qualifier
- Bound functions: "bound foo"
- Adopt uniformly:
- "get "
- "set "
- "bound "
- Fix empty string property bug
AWB: Concerned about backwards injection attacks.
MM: Too late to
(AWB: I don't recall what this was about)
## new %TypedArray%(iterable)
- Currently constructor doesn't recognize iterables, but requires an array
like. This is the behavior inherited from the Khronos spec.
- Need to use:
- %TypedArray%.from(iterable)
- Should constructor work like %TypedArray%.from?
#### Conclusion/Resolution
- Make all %TypedArray% constructors accept iterable
## new %TypedArray%("2")
DL: %TypedArray% actually coerces this to a number first to create a typed
array with length 2. The previous consensus would have to occur _after_ the
coercion step to preserve the expected behaviour.
#### Conclusion/Resolution
- Do string coercion to number before handling iterable to avoid
mishandling a string argument.
## Map Constructor and Duplicate Keys
```js
let map = new Map([["x", 1], ["x", 2]]);
```
RW: Revisiting:
-
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-23.md#consensusresolution-1
-
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-24.md#consensusresolution-2
#### Conclusion/Resolution
- No error, last property wins, eg. map.get("x") === 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140415/a4910795/attachment-0001.html>
More information about the es-discuss
mailing list