What happens with duplicate members?

[LeaVerou]

Related to #59 #61

• Are two members with the same name an error or the latter just silently overrides the former? Precedent in classes and object literals points towards the latter
• If the same member can be provided and required with no error, it seems more consistent that the same member being provided or required twice would also not be an error
• Consensus between @michaelficarra and I that it is a little weird if we decide in Are "foo" and foo distinct members? #59 that "foo" and foo are not distinct to have one override the other

[ValorZard]

Shouldn't this be an error? If I have my object "foo" and it implements both protocols A and B and both A and B have the function "coolFunc", then that shouldn't be allowed?

Otherwise, it would probably lead to hard to debug errors where depending on the order where the protocols are defined, you get different things happen when you call coolFunc(). Seems like a really easy footgun in that case

[ljharb]

On a target (class or object), silent override/shadow. On a protocol itself, error. (symbol to symbol, or string to string)

I’m not clear on whether symbol-to-string conflicts should have special behavior or not.

[michaelficarra]

@ljharb An opinion without a given reasoning is not very helpful here. Can you elaborate on how you came to these opinions?

[ljharb]

The opinion is that class authors may be piecemealing multiple protocols together, and the override/shadow behavior is necessary for ergonomic interop. However, protocol authors should imo know every protocol it's meant to be compatible with, and can benefit from the louder errors so they can fix their design before it ships.