We should also check if node is the left of the ForXStatement. Consider this case

for (const el of this.#arr);

this.#x should not be transformed into _destructureSet(this, x).

alright, just to clarify its 1st checking if its a for-of statement then checking if the next node is left of the for-of ?

If a path is a ForXStatement, how can its parentPath be an AssignmentPattern? Note that the children of an Pattern is always an expression. A statement can not be an expression.

Here is an AST example of for (o.p of arr);

// for (o.p of arr);
{
  "type": "ForOfStatement",
  "await": false,
  "left": {
    "type": "MemberExpression",
    "object": { "type": "Identifier", "name": "o" },
    "property": { "type": "Identifier", "name": "p" }
   },
  "right": { "type": "Identifier", "name": "arr" }
}

The parentPath here refers to the NodePath of ForOfStatement. NodePath is a wrapper of the AST node that provides parent association with other NodePath. In this PR We would like to make sure that member, which refers to MemberExpression here, is indeed the left of the underlying AST node of parentPath.

So we can use

parentPath.isForXStatement() && parentPath.node.left === node

The query function isForXStatement accepts an additional parameter as query, so the code above can be simplified as

parentPath.isForXStatement({ left: node })

ok, when I run the test I seem to get the same results, which shouldn't happen?

input

class D {
  #arr;
  f() {
    for (const el of this.#arr);
  }
}

output

var _arr = new WeakMap();

var D = /*#__PURE__*/function () {
  "use strict";

  function D() {
    babelHelpers.classCallCheck(this, D);

    _arr.set(this, {
      writable: true,
      value: void 0
    });
  }

  babelHelpers.createClass(D, [{
    key: "f",
    value: function f() {
      for (var el of babelHelpers.classPrivateFieldGet(this, _arr)) {
        ;
      }
    }
  }]);
  return D;
}();

The output is expected. Can you add a test case from the original issue?

class D {
  #arr;
  f() {
    for (const this.#arr of [1, 2]);
  }
}

These should be reversed.

Please also add a test for for-in.

It is a regression check on the first draft implementation: https://github.com/babel/babel/pull/11703/files/d4c0a5e8b75306f918cf2a2307e4f65130f9ea05#diff-decaf745088978f783d453709a8a8479

Ooo, ok. So we need 2 new test cases (for-of and for-in) with it appearing in the left.

👍 can just do it in the next line, or leave a comment that it shouldn't be transformed

personally I think just doing them all in the same class is fine

for (const el of this.#arr);
for (this.#arr of [1, 2]);
for (this.#arr in [1,2,3]);

the empty arr seems to be the same case?

and I would rename 1-helpermemberexpressionfunction to something like for-of-member-expression or something

for sure, will remember for next time!