lexical for-in/for-of loose end

[Allen Wirfs-Brock]

On Feb 1, 2012, at 2:13 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> Another loose end.
>> 
>> With the addition of for-of, for-in reverts back to always iterating over the property keys of an object as it does not support the generalized iteration protocols.  An implication of this is that using a de-structuring pattern as the iteration variable has very limited utility:
>> 
>>    for (let [c] in obj) print(c);  //print the first character of
>>    each of obj's enumerable property names
>> 
>>    for (const {length:len}  in obj) print(len);  print the length
>>    of each of obj's enumerable property names
>> 
>> 
>> Given this lack of utility, why should we allow de-structuring in this context?
> 
> These are not totally silly examples. I say when in doubt, let language regularity win.
    
Well, they're at least 98% silly and these were the only even semi-plausable example I could think of.
> 
> We are also thereby future-friendly in case some evolution of property keys becomes even more structured. I know, unlikely, but again: regularity when in doubt.

In which case, it would be easy enough to allow them in the future. It's always easer to relax a restriction then it is to add one.

> 
>> Eliminating it arguably increases language complexity by introducing in a bit more grammar irregularity.  On the other hand, eliminating useless functionality can be seen as as simplification.
> 
> Not useless, your own examples show use-cases.
> 
>> I'm leaning towards banning destructing in for-in.
> 
> Too nannyish!

I don't really see the consistency in trying to ban the initializer in
  for (var k=42 in obj) ;
because it is a "awful, lazy-grammar-resue error".  While adding
  for (var [c] in obj) ;

I don't actually feel too strongly either way and it is actually more work for me to disallow the destructuring pattern.  However, I am trying to find some basis for consistency in the design choices we make.

Allen