1

While I was building a generic method, I came across a compiler error, which, in my opinion, doesn't make much sense. Maybe someone could explain it to me?

When I am constrainig the generic to the method as
func foo<T: BarHaving, Decodable>() then I am recieving this Generic parameter <Decodable> is not used in function signature, even though I am using one of it's cusom extension methods.
However, in case I rewrite the generic constraint like this: func foo<T: BarHaving & Decodable>(), then everything compiles properly.

What Swift feature/behavior am I missing?
Thanks in advance.

2 
<T: BarHaving, Decodable>

means you have two generics : T which must conform to BarHaving and another called Decodable. Here, Decodable is juste a generic name i.e. it's not the Decodable protocol from Foundation.
This is the same as writing <T: BarHaving, U>

<T: BarHaving & Decodable>

means you have one generic : T which must conform to BarHaving and Decodable.

2 Likes
3

Brilliant answer, thanks Alexis!

4

Can you file a bug for the compiler to try to suggest this? It might not be straightforward but if the compiler folks can pull it off it’d prevent further confusion!

3 Likes
5

Does the language need both & and , as separators when composing protocols or could , be deprecated?

6

The only places where commas are used between protocols is in inheritance clauses and associated type bounds. I can’t think of a syntactic reason why those couldn’t use &, but it would still need a proposal to explore the ramifications.

1 Like
7

Possibly not a popular opinion, but I’d be generally in favour of removing the extra stuff from <> and keep it all in the where clause.