Destructuring instances with private fields

[jeffmo]

It just occurred to me that, due to the nature of private-field names, destructuring private fields off an instance into a local binding is not possible with the spec as-is.

I think this could be fixed with a simple tweak to destructuring grammar, though:

const {#pField: pField} = this;

would roughly desguar to

const pField = this.#pField;

Should we include this destructuring grammar in this proposal? Or defer it to a separate proposal?

(I would be in favor of including it if it's as non-controversial as I imagine, defer if it's at all controversial)

[kentcdodds]

I would be in favor of including it if it's as non-controversial as I imagine, defer if it's at all controversial

I agree. FWIW, I have no problem with what you've proposed 👍

[littledan]

Well, this makes sense, but at the same time it sort of subsumes a possible semantics for private names in object literals. If we allow {#foo: 1, bar() { return #foo } } on the right-hand side, then it's strange if this destructuring case does not introduce a new binding for #pField on the right hand side (which would be impossible to satisfy).

[kentcdodds]

Good point. I'm not certain the use case for destructuring private fields is super necessary due to the shorthand anyway. Another reason I see people destructuring is to alias things to avoid variable name conflicts, but that's less of a problem with private fields...

[jeffmo]

I'm not sure I follow:

then it's strange if this destructuring case does not introduce a new binding for #pField on the right hand side (which would be impossible to satisfy)

Did you mean "not introduce a new binding for #foo on the left hand side"?

I think I may be missing something, but AFAICT this works with future support for privates in objects too...

const obj = {#p: 42, bar() {
  const {#p: p} = obj;
  return p;
}};

(

To be clear, I am not suggesting the following destructuring syntax since it would be problematic: const {#p} = obj;. IOW: PrivateName is only permitted in a destructuring pattern if it is followed by a : to rename.

(In theory we could remove this restriction for expression-patterns where there may actually be a private binding already -- but I'd be fine with staying strict there since that seems like a pretty obscure scenario and remaining congruent between expression and binding forms is nice)

[littledan]

I meant on the right-hand side: {#foo: bar} in expression position would introduce a new identifier #foo whose access is lexically scoped to inside the curly brackets.

What you're saying seems possible, but it seems strange that in an object literal as an expression, a new unique binding is introduced, but as destructuring it refers to an existing binding. But maybe this is obvious when you use it, and I'm just being a spec pedant.

[jeffmo]

After a bit of conversation with @littledan I'm convinced that this could be confusing enough that it warrants further discussion and we should leave it to a separate follow-up proposal if ever it comes into demand.

The example he posed that convinced me was:

class X {
  #a;
  foo() {
    let {#a: a} = {#a: b};
  }
}

There's nothing technically wrong with this example, but it may be confusing enough that someone could mistakenly expect that the a binding here would be initialized with the value of b (whereas in reality this code would throw because, in this hypothetical private-object-fields scenario, #a would not be visible outside the curly braces because it is lexically private to the interior of that object).

[cybairfly]

Any further thoughts? I think the ability to destructure private fields should be possible and consistent with non-private fields:

#foo whose access is lexically scoped to inside the curly brackets
Makes sense - private member should be limited to its own closure @littledan

and therefore this also makes complete sense and should not work @jeffmo

#a would not be visible outside the curly braces because it is lexically private

All in all, to me it looks like a reasonable thing to expect from a publicly inaccessible member and the hash sign makes it quite clear that this is expected. I think this would be a welcome feature and consistent with destructuring of public fields with known and expected limitations for private ones. For your consideration:

class Thing {
    #a = 1;
    b = 2;
    c = 3;
    d = 4;
    #z = null;

    start = () => {
        this.doStuff(this);
    }

    doStuff = ({c, d, b} = this) => {
        console.log({b, d, c});
        this.doThing(this);
    }

    doThing = ({d, c, b} = this) => {
        console.log({b, c, d});
        this.doMore(this);
    }

    noCanDo = ({b, d, c, #a, #z} = this) => {
        console.log({d, c, e, #a, #z}); // won't work
        console.log({d, c, e, a: this.#a, z: this.#z});
    }
}

[ljharb]

Of course it won’t work, because you can’t declare a variable using # syntax.

[cybairfly]

Well, even with the private fields aliased, that still works better than the alternative @ljharb

    noCanDo = ({b, d, c, #a: a, #z: z} = this) => {
        console.log({d, c, e, a, z}); // would work
        console.log({d, c, e, a: this.#a, z: this.#z});
    }