#set is a mismatch vs other cases of #private

[littledan]

I can definitely see how #set is important for the utility of auto-accessors. But some things feel a bit like a surprising mismatch to me, e.g.,

• #set is a bit different from how the #private feature means in general, where # sets off a private name.
• #set introduces a new private name which isn't lexically present. Previously, there was absolutely no relationship between this.x and this.#x, but now we'd be introducing syntactic sugar that ties them together.
• Some cases that you might expect don't work, e.g., there is no way to use an operator += on an accessor x { get; #set }

I'd prefer to consider omitting this feature (and maybe reconsidering the autoaccessor feature generally, as a base for #set is a large amount of its motivation, though allowing more fine-grained decorator application also seems important and useful).

[rbuckton]

I can definitely see how #set is important for the utility of auto-accessors. But some things feel a bit like a surprising mismatch to me, e.g.,

• #set is a bit different from how the #private feature means in general, where # sets off a private name.
• #set introduces a new private name which isn't lexically present. Previously, there was absolutely no relationship between this.x and this.#x, but now we'd be introducing syntactic sugar that ties them together.

I have been considering some alternatives to the syntax as well that could potentially alleviate this concern, such as:

class C {
  accessor x { get; set as #x; }
  // or
  accessor x { get; set #x; }
  // or
  accessor x { get; #x set; }
}

• Some cases that you might expect don't work, e.g., there is no way to use an operator += on an accessor x { get; #set }

This is one of the reasons I mentioned the possibility of #set also introducing a private getter with the same spelling.

I'd prefer to consider omitting this feature (and maybe reconsidering the autoaccessor feature generally, as a base for #set is a large amount of its motivation, though allowing more fine-grained decorator application also seems important and useful).

I would be fine with dropping #set from the proposal and possibly re-introducing it (or some form of it) as a follow-on proposal, assuming whatever version of this proposal that moves forward leaves room for such a capability.

[littledan]

These are some interesting mitigations and address the problems that bother me the most. Thanks.