Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/59270

It would be nice if we could do it without using iterators. :)

Could you elaborate why you would like to avoid iterators?

Symbol.iterator is supported in chrome 43, and rest parameters are supported in chrome 47, which means that it will be difficult for users to use it without polyfill.
The benefit is better support for getter behavior, which may be rarely used.

Symbol.iterator is supported in chrome 43, and rest parameters are supported in chrome 47, which means that it will be difficult for users to use it without polyfill. The benefit is better support for getter behavior, which may be rarely used.

Thanks. We are on the same page, what I was meant for the "object pattern split" is that we handle the object rest within an object pattern as same as how we currently handle private destructuring. For example, the current private destructuring transforms

var { a, b: { i: x, #p: p }, c } = rhs

to

var { a } = rhs,
      _m = rhs.b,
      { i: x } = _m,
      p = _m.#p,
      { c } = rhs;

where the object pattern is split into three parts: part before the private access, at the private access and after the private.

Now if we take a look at the current object rest transforms,

var { a, b: { i: x, ...p }, c } = rhs

is currently transformed to

const _excluded = ["i"];
var { a, b: { i: x }, c } = rhs,
      p = _objectWithoutProperties(rhs.b, _excluded);

where b has been accessed twice, and the c is accessed before the ...p access. Now thinking ...p as if it were #p: p, if we reuse the private-destructuring object pattern split, then it should be transformed to

const _excluded = ["i"];
var { a } = rhs,
      _m = rhs.b,
      { i: x } = _m,
      p = _objectWithoutProperties(_m, _excluded),
      { c } = rhs;

where the b access is memoised and the c access is now placed correctly after p is evaluated, and the footprint increase is acceptable.

The private-destructuring assumes the iterable is pure: it does not affect how other nested patterns are evaluated. If this assumption is not held, then we will have to implement the step iterator, which, like you said, will be difficult for users without polyfill. Since we don't implement the step iterator for private-destructuring, I don't plan do so for the object-rest either.

Thanks for the detailed explanation! That sounds good.
We can keep the original as pureGetters assumption.

The private-destructuring assumes the iterable is pure: it does not affect how other nested patterns are evaluated. If this assumption is not held, then we will have to implement the step iterator, which, like you said, will be difficult for users without polyfill. Since we don't implement the step iterator for private-destructuring, I don't plan do so for the object-rest either.

Sorry I didn't understand, can you provide an example that is not pure?

See

and https://github.com/babel/babel/blob/main/packages/babel-plugin-proposal-destructuring-private/test/fixtures/ordering/.array-pattern-side-effect-iterable/exec.js

This test has been disabled because we don't support it: A proper support would require the aforementioned step iterator.

We can keep the original as pureGetters assumption.

Even with the pureGetters assumption enabled, we still need to fix the incorrect evaluation ordering. The current object-rest transform can not handle this case:

const { a: { ...r }, b = r } = rhs

because b was incorrectly evaluated before r.