Why do we prohibit redundant declarations of conformance to a protocol?

jeremyabannister · 2024-03-24T22:15:19.278Z

I was just experimenting with some ideas relating to serialization and I got blocked by a compilation error that doesn't seem necessary.

Here's the upshot:

typealias Foo = Codable & ProtocolA & ProtocolB
typealias Bar = Codable & ProtocolC & ProtocolD

struct Baz: Foo, Bar { // Redundant conformance of 'Baz' to protocol 'Decodable'

}

I found this related post with this comment:

Redundant conformance error using protocol composition

We just managed to fix this with [5.1] [Name lookup] Deduplicate nominal declarations found via resolveTypeDeclsToNominal by DougGregor · Pull Request #26177 · apple/swift · GitHub .

Doug

which I think indicates that duplicates should be permitted (but as I'm describing, that doesn't seem to be true).

Is there a good reason that we don't allow redundant declarations of protocol conformance?

ksluder · 2024-03-25T01:38:38.563Z

Are you speaking exclusively about redundancy to the right of the colon, or would you expect to be able to declare two separate conformances to Foo and Bar?

tera · 2024-03-25T05:10:10.081Z

OTOH this is fine:

protocol ProtocolA {}
protocol ProtocolB {}
protocol ProtocolC {}
protocol ProtocolD {}

protocol Foo: Codable, ProtocolA, ProtocolB {}
protocol Bar: Codable, ProtocolC, ProtocolD {}

struct Baz: Foo, Bar {} // ✅

Whether this disparity is a bug or a feature I don't know.

jeremyabannister · 2024-03-25T10:34:47.612Z

I wondering why we can’t redundantly declare the conformance. The fact that we can’t redundantly implement the conformance is no mystery to me.

tevelee · 2024-03-25T11:02:01.683Z

FYI Slava recently pointed this out on the noncopyable generics thread.

SE-0427: Noncopyable Generics

On the subject of redundant requirements in general:

SE-0427: Noncopyable Generics

A question about the new Copyable protocol: what happens if you try to manually write a redundant Copyable conformance? Would it make sense for this to result in an error or warning?

So back in the day (Swift 5.7 or 5.8, I forget now) we used to diagnose redundant generic requirements. This was disabled by default at some point and then I removed the code recently. So writing T: Copyable anywhere is just silently ignored. The compiler happily accepts this for example even though the entire where clause is pointless:
func f<T: Sequence>(_: T) where T: Sequence, T.Iterator: IteratorProtocol {}

Slava_Pestov · 2024-03-25T13:40:27.826Z

It’s not a bug or a feature, it’s two different code paths. The inheritance clause of a protocol is a shortcut for a series of Self: Foo requirements so redundancy is just ignored there. We could do the same for concrete types, I think the potential confusion from someone declaring a duplicate entry is low.

tera · 2024-03-25T16:21:33.735Z

Slava_Pestov:

It’s not a bug or a feature, it’s two different code paths.

If this disparity is intentional - that's a feature, otherwise that's a bug, I can't see how it could be anything else. Could be the case that whoever implemented it didn't have the prescribed intended behaviour to match, and whatever we have now could be retroactively called the intended behaviour, in which case the current behaviour is "a feature".

Jumhyn · 2024-03-25T16:45:18.634Z

Sure, but that requires a decision about what the "intended behavior" actually is, which isn't always obvious/trivial.

jeremyabannister · 2024-03-25T17:15:43.851Z

Are there any specific complications that you foresee if we allow the same protocol to appear twice in a conformance declaration?

Jumhyn · 2024-03-25T17:23:17.055Z

Not that I see, no. Given that we allow this to be expressed in a where clause without issue it seems fine to me to allow it directly in the inheritance clause (particularly when it's incidental by way of two typealiases; IMO that the specific code in your example at top-of-thread gets diagnosed leans toward bug).

wadetregaskis · 2024-03-26T03:18:11.203Z

I think there is an important difference between:

typealias A = P
typealias B = P

struct S: A, B {}

…and:

struct S: P, P {}

The latter probably is an error, because even though it's technically harmless it could mean the user meant to write "P2" for one of the conformances, or somesuch. There's also no good reason (that I can think of) for that syntax (I consider clumsy code generators not a good reason). It'd be wise to warn about it.

But for the former, those declarations can be spread widely apart within the code, might be complicated by the typealiases including - now, in the past, or in the future - other protocols as well, etc. It's simply less likely that it's an error. Conceptually A and B might be different things even if in practice they overlap or are even identical. And maybe they're not always identical, but it depends on some #ifs or somesuch, or they weren't identical in the past but became so but can't be removed or consolidated for backwards compatibility reasons, etc.

i.e. the compiler should really only be looking at the input text for this diagnostic, not caring about the semantics. Just checking for the same words in a single protocol list (whether that be ,-separated or &-separated).

jeremyabannister · 2024-03-26T13:22:00.988Z

wadetregaskis:

i.e. the compiler should really only be looking at the input text for this diagnostic, not caring about the semantics.

I can get on board with this, except that I would add that I also think the diagnostic for when the same protocol is explicitly written twice should be downgraded to a warning.

Geordie_J · 2024-03-31T18:11:56.893Z

Agreed. I think this should probably just be a warning