tc39 / ecma262 Goto Github PK
View Code? Open in Web Editor NEWStatus, process, and documents for ECMA-262
Home Page: https://tc39.es/ecma262/
License: Other
Status, process, and documents for ECMA-262
Home Page: https://tc39.es/ecma262/
License: Other
9.1.1 says only that the object must be an iterator and that it must inherit from %IteratorPrototype%. Leaves me wondering:
next
property be a prototype property of the returned object?I would hope the answers to these are no and no. In either case, the spec text could probably be improved to clarify.
A colophon describes the tools and resources used in the creation of a published work. Additionally, it may contain the authorship information such as who created the work, and when and where the work was created.
As an example, see the colophon from Stephen Wolfram's A New Kind of Science.
[JP22] Foe example, step 7 of “22.1.2.1 Array.from(items [, mapfn [, thisArg ]])” is described as “Assert: items is not an Iterable so assume it is an array-like object.”. This assertion can not be interpreted as a condition.
It's a lot of effort to track where the CoverInitializedName occurs, and then later determine if it's allowed to be present there.
Why not just allow it everywhere? property name = LHS, value = evaluation of RHS.
var x;
var foo = { x = 10 }; // equivalent of `var foo = { x: x = 10 }`
console.log(x) // 10
console.log(foo) // { x: 10 }
It would at simplify implementation a bit.
Maybe, if it was really necessary, it could have consistency with the behaviour of destructuring, such that
var x;
var foo = { x = 10 }; // equivalent of `var foo = { x: x === void 0 ? 10 : x }`
console.log(x) // undefined
console.log(foo) // { x: 10 }
Should cast the limit parameter with ToUint32 not ToLength (as ToLength has the unfortunate effect of allowing invalid arrays).
[JP22] In step 8-c-ii of “22.1.3.19 Array.prototype.reduceRight(callbackfn [, initialValue])”, callbackfn, which takes four arguments, called with three arguments (“«accumulator, kValue, k, »”). Need “O” at the end of parameters (e.g., «accumulator, kValue, k, O»)?
@BrendanEich, maybe expand https://gist.github.com/BrendanEich/4294d5c212a6d2254703 into a repo and link it from here?
HTML needs to specify a couple exotic objects. (Web IDL also needs to do so, if it ever gets updated to ES2015.) In many cases the behavior is "if flag X is set, throw. Otherwise, do what an ordinary object would do."
For a couple internal methods, there are pre-existing abstract operations we can use: OrdinaryGetOwnProperty and OrdinaryDefineOwnProperty. But for all others, there are not.
I see two potential ways we could spec such exotic objects:
Any advice? Is there a chance (1) could clean up parts of the ES spec that are currently duplicated?
The preface to B.3.3 lists three FiB use cases with bullets under each numbers use case. The bullets define when each use case applies. However the bullets for the second and third use cases each have the wrong bullet set. They need to be swapped.
The easiest (and I think best) fix is to leave the bullets where they are and swap the the numbered heading lines for cases 2 and 3.
(I think what happened is that I originally had only two use cases When the third was added i copied the send use case and updated the copied bullets. But then I changed the use case descript9ion line for the second set when I should have made that change for the third set).
At least based on a cursory glance, the following statement results in a completion value of "Empty":
for (let x of returnsUndefinedOrNull()) { }
Probably need an UpdateEmpty in there.
Per es6-super-construct proposal, 'super()' invocation in ordinary functions always throws:
We have a precedent already for concise methods where an occurrence of 'super()' call (DirectSuper) is an early error.
It will greatly help language usability if the same applies to ordinary functions (implementations can provide better error messages; the bugs are sure to be discovered)
The early errors for Try/Catch names includes the following passage:
"It is a Syntax Error if any element of the BoundNames of CatchParameter also occurs in the VarDeclaredNames of Block."
However, this is modified in B.3.5 to allow code of the form:
try {
...
} catch (e) {
var e = 2;
}
to run without complaint, presumably for legacy compat reasons. The spec text says:
"It is a Syntax Error if any element of the BoundNames of CatchParameter also occurs in the VarDeclaredNames of Block, unless that element is only bound by a VariableStatement or the VariableDeclarationList of a for statement, or the ForBinding of a for-in statement."
But this means that the following is also allowed:
try {
...
} catch ({stack, code}) {
var stack = 1;
var code = 2;
}
What's the motivation for allowing the destructured form, given that there will be no legacy concerns in that case? One could imagine the spec could instead read:
"It is a Syntax Error if any element of the BoundNames of CatchParameter also occurs in the VarDeclaredNames of Block, unless BoundNames contains a single element and that element is only bound by a VariableStatement or the VariableDeclarationList of a for statement, or the ForBinding of a for-in statement."
In the ES6 spec., there is no check that a destructuring let/const/var actually introduces any bindings.
For example:
let ;
is a syntax error, but (updated 10/22/15)
let { } = obj;
is valid syntax that does nothing (it doesn't add any new variable bindings).
There are reports that some ES6 developers are encountering bugs cause by complex destructing patterns that unintentionally don't introduce any bindings.
This seems like a design bug in ES6. It would be trivial to specify that this is an early syntax error.
In 13.3.1.1
LexicalBinding : BindingPattern Initializer
- It is a Syntax Error if the BoundNames of BindingPattern has no elements.
In 14.1.2
FormalParameter : * BindingElement*
- It is a Syntax Error if the BoundNames of BindingElement has no elements.
Note that this is a breaking change for any program that actually contains such empty binding patterns. So there is some risk to making this change.
Hi,
I understand this is an ambitious request, and probably aimed at ES8 or even ES9, but considering the direction many web based technologies are heading, this request definitely makes sense in my mind.
This request is for optional, TypeScript-esque, static typing for ECMAScript.
There are tools and transpilers that already support optional static typing, and Google are also looking at supporting optional static typing directly in their virtual machine with SoundScript. That being said, a formal and specified syntax for optional static typing in ECMAScript would obviously be beneficial in numerous ways. It would allow developers to remove one or more layers from their workflow, therefore improving productivity across the board, and it would also allow virtual machines to produce highly optimized native code from the source files it consumes. I am honestly struggling to think of downsides.
I believe the time is now right to consider adding option static typing to ECMAScript. The language is evolving extremely well now, and optional static typing is one feature that is still sorely missed.
If required, I am willing to compose a full proposal to support this request.
Hi, guys! Sorry if I create some stupid or incorrect issue.
Is there any plans to look into pattern matching and currying?
This would be great when breaking up strings into multiple lines in the source code. It would save us from writing a +
for every line break. This is a feature present in C, Python, and Ruby. It's most useful when your style guide enforces max characters per line and you want to keep a level of indentation.
Example:
// gettext is used for translations
gettext('This is a string literal '
'written in multiple lines');
should be transpiled to a single string.
// gettext is used for translations
gettext('This is a string literal written in multiple lines');
Other thoughts:
Chromium (V8) has implemented "do expression" parsing: https://chromium.googlesource.com/v8/v8/+/b6596aa73b069aaa6e52291c3756b0e0f0e483b6
I would like to read about this ES7 proposal, but I can’t find anything on the Web (ecmascript.org seems to be down). Is there a GitHub repo for this feature? If so, could you add it to the “Current proposals” table?
Not sure if this is a good place to ask this question. If not, I'm sorry for the noise. Could you then point me elsewhere perhaps?
I've just read this post here: http://www.2ality.com/2014/09/es6-modules-final.html
Which claims that the module system will support both sync and async loading. Which I like. But it made me wonder if/how well async loading would work for deeper dependency trees. E.g. if I had a project with 20 level deep dependency tree (at its deepest point) and my server would take on average 200ms to respond, then it would take about 4000ms minimum to execute any/all of my scripts, right? Or is there something I am missing?
If I interpret the situation correctly, what is the conceptual response to this scenario? Try to limit the tree depth? Concat everything just like it happens often with ES5? Something else?
There are two ways that a function in ES6 can be "just a function, not a constructor":
new.target
, and throw an exception if new.target
is undefinedIn https://code.google.com/p/v8/issues/detail?id=4538 , V8 engineers mention that there are different semantics to these two strategies: It changes whether IsConstructor is true. IsConstructor is called all over the place, but the most common callsites have implications with cross-realm access (in a way that's a bit outside of the direct ECMA spec): In places that construct, such as new or Reflect.construct, IsConstructor is called to see if an exception should be thrown.
So there are two places where an exception could be thrown, depending on the strategy: In the caller (the place where new is invoked, for example) and in the callee (the actual running constructor). This is visible in cross-realm settings because a different sort of exception will be thrown when the callee is in a different realm. In the former case, it will be the caller's realm, and in the latter case, it will be the callee's realm.
In offline discussion at the last TC39 meeting following Yehuda's call construct
proposal, a few committee members discussed these two different implementations of implementing [[Call]] and [[Construct]]. The argument made was that, since Reflect.construct
requires a constructor for newTarget, the distinction should be unobservable and it doesn't matter whether we go with separate [[Call]]/[[Construct]] methods or a conditional within the constructor. However, in this exception-throwing case, there appears to be a significant difference.
I bet this subtlety was entirely accidental, and that better semantics would be for the caller's realm to always throw the exception. This would give more information to users and be reasonable to implement.
The grammar in 7.1.3.1 uses triple colons (:::
), but during the html page creation it is somehow changed to single colons <emu-geq>:</emu-geq>
.
[JP22] 15.2.2.1 Bullet 6 says "It is a Syntax Error if MouduleItemList Contains NewTarget" and I was first puzzled on what this "NewTarget" means. Isn't it more kind to just use "new . target" (in typeface)? The problem stems from the fact that identifier "NewTarget" is used in multiple ways throughout the document, and it might be difficult to resolve. However, I guess the above change will resolve the problem here. (I also noticed that a period is missing at the end of the sentence.)
Derived from https://bugzilla.mozilla.org/show_bug.cgi?id=1135377
ES6 21.2.2.2 steps 2.1-2 don't cover the case when index
points a trails surrogate of the surrogate pair in str
.
Here's testcase:
var r = /\uDC38/ug;
r.lastIndex = 1;
var str = "\uD83D\uDC38";
r.exec(str);
r.lastIndex
points trail surrogate \uDC38
in str
. In step 2.1, Unicode
is true
and Input
becomes a single element list with U+1f438
. So listIndex
cannot point the trail surrogate character in step 2.2.
There currently is nothing in either the spec of for-in, or the spec of proxies' [[Enumerate]] method, that would ensure that all keys are converted to a string. Consequently, a for-in over a proxy could produce arbitrary key values. That may break code that assumes it can only get strings, and is particularly strange because [[Enumerate]] on ordinary objects explicitly excludes symbols to avoid this problem.
(As a secondary consequence, the sample implementation in 9.1.11 also is broken, because if proto
is a proxy, it might return equivalent keys as different values (e.g. "10"
vs 10
), such that their lookup in the visited
set fails due to the lack of canonicalisation.)
To fix this, [[Enumerate]] on proxies probably needs to create a wrapper iterator that invokes ToString on each value returned from the trap.
The following links yield 404 errors:
http://tc39.github.io/ecma262/#sec-arrow-function-definitions-static-semantics-early-errors
- If the [Yield] grammar parameter is present on ArrowParameters, it is a Syntax Error if the lexical token sequence matched by CoverParenthesizedExpressionAndArrowParameterList cannot be parsed with no tokens left over using ArrowFormalParameters as the goal symbol.
The goal symbol should be ArrowFormalParameters[Yield] instead of ArrowFormalParameters.
Why ecma262 lexical grammar is not a regular grammar (that can be represented as Regular Expressions)?
The leading underscores are missing at http://tc39.github.io/ecma262/#sec-object.prototype.__proto__
This is for HTML/ES integration. HTML has a concept of script which contains a few useful pieces of information. Notably, it contains a "muted errors flag", which is set based on whether the script was retrieved in a cross-origin manner.
When performing NextJob's "implementation defined unhandled exception processing", I need to be able to retrieve the current "HTML script" given the information available to me in the ES context.
I would have thought this would be simple: I'd simply get whatever concept ES has for "script", and add a pointer between them associating "HTML script" and "ES script". Or, I could even try to get rid of "HTML script" entirely, and just store a couple things on the ES script.
But, I can't find any concept of script in ES! :(
The closest thing I can find is the top-level execution context scriptCtx created by ScriptEvaluation.
So far the best I've come up with is:
Does this seem vaguely legit? I don't like "all execution contexts created from".
Now that the spec is distributed as a web page, it should have a favicon.
We don't even know who can edit it, and then we could clear up stuff like entry criteria vs. exit criteria.
Update: Link to proposal: https://github.com/tc39/proposal-regexp-legacy-features
All web browsers expose non-standard properties on the RegExp constructor, that are updated each time a match is done.
The list of properties that are exposed by all common browsers are the following. They typically expose other properties not mentioned here, but not shared by all implementations:
$1, $2, $3, $4, $5, $6, $7, $8, $9,
and (in pairs, where the first and the second one return the same value):
input, $_
lastMatch, $&
lastParen, $+
leftContext, $`
rightContext, $'
Some observations:
It would be useful to specify them. I think that the following should be required:
RegExp#exec
method. This is useful if we want, in some future, separate the part of RegExp#exec
that does the real work, and the part that does stateful updates on various objects.Consider
let P = new Proxy(Int8Array)
let a = new P
You might not have guessed, but this will throw a type error. The reason is the, um, creative way in which the %TypedArray% base constructor tries to figure out what typed array instance to create, namely, by re-traversing the prototype chain from newTarget up to itself, looking for the closest [[TypedArrayConstructorName]] internal slot -- but that will never hit the Int8Array constructor in the example above, because the algorithm (22.2.1.2.1 AllocateTypedArray) skips from the proxy to its target's prototype directly.
More generally, I argue that this semantics is fundamentally bogus. It doesn't just break proxying typed array constructors, the prototype walk also is observable through proxies in other places of the prototype chain -- which might change the very prototype chain through side effects while you go.
More importantly, it breaks a highly desirable invariant for object construction: preferably, constructing an object should only be keyed on two inputs: (1) the base constructor (for internal fields), and (2) new target (for [[Prototype]]). With the current walk, it is keyed on an arbitrarily large set of objects, plus potentially random computations. That makes optimisation much harder: even to merely decide whether we can take a fast path for construction, we already have to look at the entire prototype chain. Under this semantics, instantiating (subclassed) typed arrays is inherently penalised.
So, as we all know, prototype chain walks are a bad and utterly unreliable tool for figuring out instance relations in JavaScript. The spec should better avoid relying on it for its innards. :)
Fortunately, we could avoid it easily for typed arrays. I propose that instead of having the base constructor re-walk the prototype chain, it should take the derived typed array constructor as an argument and read the [[TypedArrayConstructorName]] slot from there. Then proxying would work just fine, and the aforementioned invariants would be maintained. It’s also simpler. While this technically is a breaking change, it is unlikely that code in the wild currently invokes the %TypedArray% base constructor directly (in part because not all browsers implement it yet), so the compatibility hazard seems neglectable.
There's an idiom called "self-defining functions". It usually looks like this:
var foo = function() {
foo = ...
}
Some users (e.g., GWT, which has widely deployed compilation output all over the web), write a slightly different version, used to implement Java static {}
class initialization blocks that run just once, but with checks all over the place to run it if it hasn't been run yet:
function foo() {
foo = ...
}
Many module systems wrap all the definition code in a try/catch. Google does this internally, and the JS code in Reddit seems to have had a similar treatment. If we have a sloppy-mode block-scoped self-defining function as follows:
try {
function foo() {
alert("hey!")
foo = () => {}
}
} catch (e) { }
foo()
foo()
then (I believe) all browsers pre ES2015 (IE10-, WebKit, Firefox and Chrome) would alert "hey" just once. This is the long-standing web-compatible intersection, as far as I can tell.
However, ES2015 semantics would say that there are two bindings--the inner lexical one inside the try block, and the outer function-hoisted one. The line redefining foo will redefine the lexical binding, and leave the hoisted one in place. So "hey!" will be alerted twice. This is IE11 and Edge semantics, as the first implementors of something approximating Annex B 3.3.
I don't think these semantics are web-compatible. They break Google Inbox, though Inbox does not currently try to work on IE. More generally, the breakage is just the result of a combination of two techniques that independently work and are independently widely used--self-defining functions (through a rather odd syntax that GWT has been emitting for years), and surrounding function definitions by try/catch (which many module systems seem to do). It is, at the very least, a refactoring hazard to prohibit them together.
I think it's possible that this breaks the web even though IE11 has been shipping for a couple years because
I think the second binding, the lexical one, isn't necessary to get something working that will allow references to lexically scoped variables from hoisted functions and be within the intersection of all browsers' semantics. An alternative semantics suggested by adamk@ is to have just one var-like binding, initialized to undefined, which is set at the top of the block where the function declaration occurs to that function value. There would be no conditionality semantics, and no multiple bindings for the same variable name, so the result would be easier for both users and implementors to understand.
Now there is no way to exit from forEach loops.
iterable.forEach(item => {
if (item == 'what we need')
return Symbol.breakLoop // loop breaks here
})
Traditional equivalent
for (let item of iterable) {
if (item == 'what we need')
break
}
Or just Symbol.break
.
Array has some methods which supports functional coding ,such as map,reduce..
Say I wanna do some transforming with an array and log the result :
var result=[1,2,3].map(function(v){
return v+1;
});
console.log(result);
It'll be better if we can log the result without declaring variable result
First I think about this:
[1, 2, 3].map(function(v) {
return v + 1;
}).some(function(v, i, a) {
console.log(a);
return true;
});
But this is aginst the purpose of some
.
I need something like this:
Array.prototype.feed = function(callback) {
callback(this);
};
[1, 2, 3].map(function(v) {
return v + 1;
}).feed(function(a) {
console.log(a);
});
In practice, we often need map / filter / reduce arrays and deal with the result. So it'will be a pleasure if array has a feed method (more than a pleasure if Object.prototype also has that:) to support more functional programming
Sorry for my poor English, Hope I can be understood:)
For consistency with TDZs implied by lexical declarations ('let/const')
On Jan 9, 2015, at 7:43 AM, Erik Arvidsson wrote:
Happy New Year!
(I don't know which thread is the active thread.)
https://github.com/tc39/ecma262/blob/master/workingdocs/ES6-super-construct%3Dproposal.md
Point 12: If a class definition does not include an explicit constructor definition, it defaults to: constructor(...args) {super(...args)}; if the class has a non-null extends clause. Otherwise it defaults to: constructor() {};.
This is problematic since we have to evaluate the extends expression to know if it is null or not. This means that the default constructor needs to be:
constructor(...args) {
if (%extendsValue !== null) super(...args);
}
where %extendsValue is the result of evaluating the extends expression and it has to be captured for later references.
erik
Hey all, I was just doing some digging on do expressions
and found: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-29.md#conclusionresolution-2
Conclusion/resolution
- do-expressions as generailsation of block statements
- Progresses do-expressions to the next state in the new process.
However I don't see them mentioned in the proposals table.
What should it look like?
See http://yehudakatz.com/2011/09/13/a-proposal-for-es-next-proposals/ by @wycats for some inspiration.
Sorry if this is the wrong place to post this (or if someone has already proposed it).
Lately I've been writing quite a bit of code which needs some things to be lazily evaluated. So far I've just been using functions with empty parameters, but having lots of empty function parameters all over the place makes things unnecessarily verbose and hard to read. Some examples of where this might happen:
// Logging a value after a specified amount of time.
setTimeout(function(){console.log("Ten seconds have passed")},10000);
setTimeout(()=>console.log("Ten seconds have passed"),10000);
// Generic library that lazily evaluates chained methods.
bigArray.map(x=x*2).filter(x=>x>10).sort((a,b)=>a-b).exec()
As you can see, a function
expression with empty parameters has 10 unnecessary characters, while an arrow function with empty parameters has 4 unnecessary characters.
My first thought was to wrap expressions to be lazily evaluated in backticks, but they are now used for template strings. Perhaps putting a @
or a #
before an expression wrapped in parentheses or statement wrapped in curly braces would be acceptable?
As for evaluating the expression/statement, I'd think that expression()
would make sense. This would mean that if the chained methods example above was used, then the .exec()
or .done()
method could just be ()
. The examples above might then become:
setTimeout(@(console.log("Ten seconds have passed"), 10000);
bigArray.map(x=x*2).filter(x=>x>10).sort((a,b)=>a-b)()
I have found that some websites don't work properly under Annex B 3.3. When interacting with Reddit comments, there is code with the following pattern (in the global scope):
try {
function x() { }
} catch { }
x()
x isn't hoisted at all under Annex B, but it must for compatibility with the current version of Reddit.
I could imagine the annex having a second rule, which is when a sloppy-mode block-scoped function declaration is made in the global scope, the appropriate property of the global object is also set when the function declaration is reached (unconditionally, since this actually couldn't lead to an early error). I think this would fix that website, but would it cause any other problems?
[JP22] This is not a factual issue but a meta issue for the style of standard document:
Many contents of the NOTE for the Language seems to be specifications expressed in English rather than just an informative note. I’ve got that from notes in 13.3.2.4, 13.7.5.9, 13.10, 13.11. It looks that a subclause entitled “Summary” might be useful to guide the readers of this document.
See https://esdiscuss.org/topic/exception-type-for-invalid-operations for background. I'd like to update the definition of TypeError (currently "Indicates the actual type of an operand is different than the expected type.") to something that more accurately explains how it is used as the catch-all fallback error.
Here's some possible wordings. We can wordsmith in this issue thread then I'll do a PR:
In Chrome 46, we shipped a change to date formatting per ES2015 that a missing time zone should be treated as local time (where in ES5 it was treated as UTC). See https://code.google.com/p/chromium/issues/detail?id=543320 for details, in particular comment 5 (which lays out the exact difference).
Given the breakage, and that no other browsers seems to have shipped this change, it seems like the easiest thing to do would be to revert to the ES5 behavior. But I'm not sure what prompted the change in the first place, so it's hard to weigh such a change.
When for-in is invoked directly on a proxy, then it simply executes the iterator returned by the proxy handler. That prescribes a much more rigid iteration sequence than for regular objects that breaks existing implementations. In particular, implementations often want to compute the list of keys before the iteration starts, which would currently be forbidden due to observable calls to iterator.next.
This is inconsistent not just with regular objects, but also with enumeration over regular objects that have a proxy as their prototype -- because in that case the object's [[Enumerate]] still has the liberty to invoke the prototype's [[Enumerate]] whenever.
To fix this, we probably need to loosen the spec for proxy [[Enumerate]], such that it does not prescribe that the original iterator is invoked in lock-step.
While browsing the spec I typically end up looking for something like "[[Call]]" which exists in multiple places (Functions, Proxies...). In this case it is not always immediately clear in which section you are.
It would be nice to highlight the current super-section somehow. One option would be to show it in the expanded TOC, another one might be using fixed Breadcrumps at the top of the specs.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.