No, it's equivalent to the following:

  (function (a) { return a * a; }).bind(this);

On an entirely different note, I never liked how generators are marked with an asterisk. A generator isn't special, it is just a function returning an iterator. A generator should be able to return normally as well as yield.

But in a generator function the iterator is returned immediately, before any of the code in the function runs, so how would it return anything else?

For example:

  function* f() {
      console.log("function commencing!");
      for (x of [1, 2, 3]) {
         console.log("yielding " + x);
         yield x;
      }
  }

  var it = f();
  console.log("iterator returned from function:", it);
  console.log(it.next().value);

  "iterator returned from function:" Generator {  } Scratchpad/1:19
  "function commencing!" Scratchpad/1:11
  "yielding 1" Scratchpad/1:13
  1

   if (isTuesday())
     return something;
   else
     yield somethingElse;

Oh, that's interesting, I didn't know ES6 implemented generators that way. That's really weird.

EDIT: Looks like PHP does the same thing. Hmm, I can see the merits of an asterisk, then.

(PS, repository is here: https://github.com/espadrine/New-In-A-Spec)

  for (var [key, val] of items(x)) { alert(key + ',' + val); }

  items(x).forEach(function(key, value) {
    alert(key + ',' + val);
  });

Also, can someone in the know care to tell me why that is that those additions for what is the end rather basic functionality is coming so late to the language?

    items(x).forEach(function(key, value) {
      alert(key + ',' + val);
    });

> It also brings up the question of interpolation, why do we even have to use + in the first place?

Did you miss the last item, "quasis"? `You are ${age} years old.`

> Also, can someone in the know care to tell me why that is that those additions for what is the end rather basic functionality is coming so late to the language?

Because unlike most languages, there's no canonical implementation.

Mozilla, who actually holds the trademark on the name "JavaScript", totally tried to evolve the language since the beginning and even shipped e.g. JavaScript 1.7 (which had generators, iterators, let, array comprehensions, and destructuring assignment [1]) with Firefox 2 in 2006, but Firefox just didn't have the market share for authors to start using the new features, and no other browser implemented any of them. That deadlock was only broken by Brendan Eich using corporate politics rather than hacker-style "putting it out there": rounding up all the big browser makers (of course, it helped that Apple and Google had just broken into the scene), and convincing them to commit to implementing new features decided on by the committee they formed, TC39 (and to update their browsers at all, ahem IE ahem).

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...

The only way is to use:

  for(var key in obj) {...}

    Object.keys(obj).forEach(function (key) {
        var val = obj[key];
        
        // use key and val here
    });

    x.forEach(f);

    items(x).forEach(x);

https://www.mozilla.org/en-US/foundation/trademarks/list/

TIL!

And you're right about TC39, I probably should have said "joined", not "formed", if I could edit my comment I would.

I don't think my comment was a gross misrepresentation of the historical context, though.

Back when IE was stagnating, when nobody was working on anything more than maintaining IE6, TC-39 (the technical committee that works on ECMAScript) was working towards a 4th revision of the standard (i.e., ES4), incorporating a lot of quite reasonable things (like the above) but also quite a lot of things based on very recent research. There was pushback against quite so aggressively moving forward in a single revision, especially incorporating so much from academia not already proven elsewhere (the browser space is very conservative about breaking existing content, so if something that turned out to be a bad idea shipped, it'd be very very hard to get rid of). In the end, there was relatively significant pushback once MS reappeared from themselves, Yahoo, and a number of other contributors.

Moving forward, the plan was essentially to tidy up the ES3 spec with minor additions, which was originally referred to as ES3.1 but eventually standardised as ES5. ES6 is the next revision of this branch of the standard.

ActionScript 3, as Flash uses, is based on one of the drafts of ES4, and prior to the abandonment of Flash development, the intention was to continue to evolve the language separately to ECMAScript.

I would think Internet Explorer being the dominant browser had something to do with it.

On the other hand, most iterables have their own methods to loop around values. Arrays and Maps both have a .forEach() method.

Bit of an error here. The array comprehension uses "in" which will iterate over the indexes of A and B. While this is technically valid, no one would look at that and expect it to return the string concatenation of all the indexes of A and B :)

(There's no certainty that the syntax will be kept, though, see this[1] about deferring it to ES7 to generalize the syntax for parallelism, and this[2] to make async promises and generators work together.)

[1]: https://speakerdeck.com/dherman/a-better-future-for-comprehe...

[2]: https://docs.google.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU/...

A bullet I retrospectively think we should have bit a long time ago. It would have sent a strong message that you either make sure that your browser is top notch or it will be left behind to bite the dust of the power horses.

Now that Microsoft is feeling the heat under its ass (from FF, Chrome and Safari), they're making sure IE is not ridiculously worse than the competition, that it auto-updates, they're engaging the community, creating libraries, etc.

Actually Chrome is a complete mess ES6 compatibility wise.

Most of the interesting stuff is unimplemented still, and what is there is hidden in options the user has to specifically enable.

Sure, the standard is (now) only due for 2015, but Chrome dragging its feet is also one of the reasons for that. And it's not like FF waited for the standard to be stamped and released to have the implementations according to the standard already working.

Also, and that's only personal opinion, but there's a limit to the customer is always right. What if we create a new super highway one day with flying cars, are we going to punt on moving on because some people like their combustion engine pieces of junk? It's also our jobs to make people understand that jumping on the latest technology is in their best interest. Leveling the field to the lowest common denominator brings everyone down in the end and really hampers creation and innovation.

And that is the reason why Javascript is so far behind modern languages in so many areas.

At some point, it's no longer worth the business of the small number of e.g. IE6 users to put the extra effort in creating a site that can work in it.

A language that doesnt evolve is a dead one.

> JavaScript will have gone from a nice simple, elegant language

It's neither nice,nor simple nor elegant.To many WTF,to many edge cases,and a verbose syntax.

The code you are writing today will still run with ES6.

Nobody is forcing you to use new features.

You may like ES5,you may like how one writes ES5 code.That's not my case and the case of many developpers using javascript everyday. These features, we should have had then back in 2007 with ES4.So this isnt even an evolution,this is a catch up.

> C++ 11, incomprehensible to both humans and machines

I prefer devs using the same "incomprehensible" language than having to use 10+ transpilers because devs dont get what they want with javascript.

Again,nobody's forcing you to use ES6 new features,so you shouldnt force people into what you deem "nice,simple and elegant". Devs are forced to use JS one way or another,so let's make it so all devs can at least work with it instead of trying to force everyone into a paradigm everybody is not going to agree with.

And the best is yet to come with structs,guarded types,async/await keywords,more data structures,...

Global Scope: not fixed. No integer: not fixed. Syntax to resemble JAVA more closely in a class-less language that already as 9999999999999 class libraries: FIXED

Adding an integer type is far easier said than done. It was decided to leave that hard problem to ES7; integer type (or types!) are certainly coming.

For most cases of X, some form of declaration that is scope bound.

Look at e.g. Perl, it changes quickly in this way, with very good backwards compatibility. [Also see strict mode, of course.]

Edit: That said, new keywords like those let/const/module/extends etc should work fine. Please give me them today.

Edit 2: I have been cursing the lack of multiple returns this week. It is a pain returning a hash/object or an array. That really isn't supported, from browsing the standard? :-(

Why is that?

  let rational = (a, b) => [a, b];
  let [numerator, denominator] = rational(38, 4);
  let reduced = rational(numerator/2, denominator/2);

<Cough> Obviously because I'm blind? :-) Thanks.

* `new StructType({x:uint32, y:uint32, color:Color})` - looks like integers to me..?