Throw on duplicate properties?

[littledan]

For private state, in tc39/proposal-private-fields#22 , there is an issue of a field getting redefined with the same name, and what the semantics are. The resolution there seems to be to throw for duplicate fields. Would this make sense to do for property declarations as well? That would obviate the need for the "this.x = this.x" semantics, as a runtime error would be thrown in the case where it makes sense.

[michaelficarra]

I prefer throw. 👍

[erights]

Sounds good to me.

[jeffmo]

Although I am a reasonable human and prefer to know as soon as possible when I have a mistake, I don't think throwing on duplicate property would be very consistent with either methods (which permit duplicates) or object properties (same).

All of the conversations we've had in the past where we tried to prevent duplicate members from existing on a construct have failed for various reasons, and so I think it would be reasonable to expect the same conclusion and user expectations here.

We could make an argument that fields are especially susceptible to error due to inheritance, but I don't think that holds up very well considering that we wouldn't be banning multiple assignment (which could occur in unfortunate places along the inheritance hierarchy as well).

[bakkot]

I agree with @jeffmo's thinking, but it's worth noting that not throwing implies that properties are configurable.

[littledan]

@bakkot I think we're just discussing whether there should be a special check for the property's existence when setting/defining the property. Let's leave the configurable discussion for a separate thread. I am also sympathetic to @jeffmo 's reasoning.