Can provided members satisfy other protocols?

[LeaVerou]

This is somewhat related to #23 and #60.

Consider this:

protocol A {
	requires a;
}

protocol B {
	[A.a] () { /* elided */ }
}

Which of the following throws, if any?

class C1 implements A, B {}
class C2 implements B, A {}

1. Both throw
2. C1 throws
3. C2 throws
4. None of them throw

Basically:

• Can provided members of one protocol satisfy required members of another protocol applied on the same class?
• If so, does the order of application matter?

If I’m reading things right, it appears that the current behavior is that protocols are checked+implemented sequentially, as if we were independently calling Protocol.implement(), in which case C1 would throw. While simple to spec, this does not seem optimal for authors.

I wonder if a slightly more intuitive behavior might be that protocols are first (conceptually) flattened, with provided members of one protocol being able to satisfy required members of another, and the host class only has to satisfy what remains. In that case, none of them would throw.

With that change, these would be equivalent (see #60):

protocol A {
	requires a;
	foo() { { /* elided */ }
}

protocol B {
	[A.a] () { /* elided */ }
}

class C implements A, B {}

protocol A {
	requires a;
}

protocol B implements A {
	[A.a] () { /* elided */ }
}

class C implements B {}

cc @michaelficarra @ljharb

[ljharb]

That makes sense to me, as long as a conflict still throws.

[michaelficarra]

If I’m reading things right, it appears that the current behavior is that protocols are checked+implemented sequentially, as if we were independently calling Protocol.implement(), in which case C1 would throw.

Yep, that was my current thought.

Order-independence sounds nice, but I'd have to see it written up algorithmically before I was convinced it was actually possible in general.

[LeaVerou]

If I’m reading things right, it appears that the current behavior is that protocols are checked+implemented sequentially, as if we were independently calling Protocol.implement(), in which case C1 would throw.

Yep, that was my current thought.

Order-independence sounds nice, but I'd have to see it written up algorithmically before I was convinced it was actually possible in general.

As a rough sketch:
For n protocols P₁, P₂, P₃, ..., P_n, define a new P_flattened protocol with:

• P_flattened provided members = union of all provided members of P₁, P₂, P₃, ..., P_n
• P_flattened required constraints = union of all required constraints of P₁, P₂, ..., P_n - union of provided members of P₁, P₂, ..., P_n
  Or, depending on What should happen if the same member is both required and provided? #67, it could just be union of all required constraints of P₁, P₂, ..., P_n.

Then, instead of applying P₁, P₂, ..., P_n, we'd apply P_flattened sequentially.

Once we have more specific constraints (#4) instead of a simple union it gets a little more complicated, but I think it's still doable.

[michaelficarra]

Okay, I think this is fine as long as the sets of required and provided names are non-overlapping (a possible outcome of #67).

[LeaVerou]

Okay, I think this is fine as long as the sets of required and provided names are non-overlapping (a possible outcome of #67).

Yes, that's why I think #67 should not be an error. If protocols can satisfy other protocols, then protocols satisfying themselves is only a degenerate form of the same thing. Yes, it's pointless in most cases, but something being pointless is not reason to make it throw.

[michaelficarra]

something being pointless is not reason to make it throw

That's sometimes true, like when you need to make things from non-coordinating authors work together. But this is a singular language construct. It's very likely that the author has made a mistake and a static error would help them catch it. If we can't come up with a use case, we should have a static error for it and we can relax it later if necessary.

[ziadkh0]

I believe static errors should not be used to help authors catch a likely mistake, that's the job of linters.
An example of construct that's very likely a mistake (because it's useless) but does not throw an error is x = x.

[michaelficarra]

I believe static errors should not be used to help authors catch a likely mistake, that's the job of linters.

Who said it's a likely error? We've already established that it will always do nothing (under this proposal). I think I'd be fine with posing this question to committee and seeing if we'd like to establish normative guidance about this kind of thing.

An example of construct that's very likely a mistake (because it's useless) but does not throw an error is x = x.

with({
  get x() { console.log('get'); return 0; },
  set x(a) { console.log('set', a); },
}) {
  x = x;
}

[ziadkh0]

Who said it's a likely error? We've already established that it will always do nothing (under this proposal).

x = x will also always do nothing in strict mode without throwing an error.
Other examples of things are allowed and always do nothing include: any statement that consists of only a literal (except template string literals) and any dead code like if (false) { ... }.
{a: 1, a: 2} is another construct allowed in strict mode and is likely a mistake that a static error would help catch.

I think I'd be fine with posing this question to committee and seeing if we'd like to establish normative guidance about this kind of thing.

Nothing against that 😄