@ariya can you respond to the estree issue about rest and defaults? I think we may want to take acorns approach here.

@mikesherov I'm not sure why we want to deviate from the existing SpiderMonkey AST for this case.

Just a heads up: I was doing some experimentation and found that there's no good way to support both the harmony branch rest property and the newly-agreed Acorn-like approach (having the rest param in the params array) at the same time. This is because code exists that loops over the params array and then checks to see if rest has a value. That means adding the rest param into the params array would result in double evaluation of a rest param.

So we can really only do one or the other but not both (as opposed to handler and handlers, for instance).

@nzakas no way to add a flag rather than doing a second loop?

Sure, but that's still a breaking change. My point is that existing code will break if we support both at the same time. If we need a breaking change, might as well go all the way and remove rest.

@nzakas I see, you mean consumer code. I'm +1 for removing all the way.

@jeffmo ^ ?

Agreed, let's rip the band-aid off

Hmm, maybe I missed something, but when did I discuss keeping the compatibility? Rest parameter was not feature in 2.0 anyway.

@ariya : I think the breaking-change-ness is only in reference to a breaking change within the harmony branch

@ariya we sort of glossed over it in the meeting quickly. Glad we're all in agreement to just rip off the baindaid!

@nzakas, you have sample code for the switch to restElement?

Assuming you mean consumer code that would be confused by having both, escope is a good example: https://github.com/estools/escope/blob/master/src/referencer.js#L221

@mikesherov Anything here that is still blocking 2.1?

@ariya, yes, the switch from defaults/rest properties to resElement/AssigmentPattern