What should happen if the same member is both required and provided?

[LeaVerou]

Consider:

protocol P {
	requires a;
	a () { /* elided */ }
}

What should happen?

Options:

1. Error
2. P essentially has no required members, as it is trivially satisfying itself (as a degenerate case of Can provided members satisfy other protocols? #61)

I’m personally leaning towards 2, but I suspect @ljharb @michaelficarra may have a different opinion.

[ljharb]

That should be an early error, even - why can you require and provide the same thing? That makes no sense.

[michaelficarra]

In the current proposal state, I think the answer depends on an unresolved question (edit: see #76): if a protocol provides a symbol that is already present on a class when it implements the protocol, does the class member get overridden, does it do nothing, or is that an error? Personally, I would expect it to do nothing (the class author is intending to override the protocol-provided behaviour). Assuming that, in this case, the protocol would be valid, but implementing it would always either fail (if the class does not have the required symbol) or do nothing (if the class already has the provided symbol).

Assuming the composed protocol behaviour from #61, I guess it would just always do nothing.

In either case, we could also decide to statically ban such protocols, as @ljharb suggests. I don't know if I have an opinion on that yet, but the safer choice would be the more restrictive one (banning them) because we could always relax the restriction in the future.

[ljharb]

Absolutely I think that if the class itself overrides something from a protocol, the class's implementation should "win" - the important conflicts to error on are between protocols.

I think that any time a protocol provides something, it's implicitly required. Having a provided implementation that can be "removed" by shadowing it with undefined, or deleting it, or something, while still considering that a valid implementation of the protocol, seems absurd to me.

[michaelficarra]

I don't understand your second paragraph.

[ljharb]

protocol P {
  foo() {}
}

class A implements P {}
class B implements P {
  [P.foo] = undefined;
}

const a = new A();
const b = new B();

assert(a implements P);
assert(!(b implements P));

[michaelficarra]

Well the implements operator just checks for presence of all the required and provided names, so both would implement P. Now if P.foo was deleted from b, it would not implement P. If you think the implements operator should do more than just check for presence (such as GetV and check not undefined/null), open an issue. But I'd prefer it not trigger getters, so I think presence is best.

edit: You've got me confused, actually. The implements operator works on the class (A or B in your example), not an instance. I don't think we have a way to query an instance. The comment about presence vs value tests still stands, though.

[ljharb]

Like instanceof, i'd expect implements to have its LHS be the actual thing participating in the protocol. Promise does not implement Thenable, a promise does.

[michaelficarra]

It sounds like you want #58 (comment).

[ljharb]

Maybe? I think it doesn't make any sense for the class to be the thing that implements the protocol when it's the instance that participates in it.

[bakkot]

There are many, many protocols that involve both static and instance members

Can you give some examples? Having concrete things to talk about might help inform some of these questions.

[michaelficarra]

@LeaVerou I think you meant to post on #69?