extension ProtocolA {
func description()
func methodA(param1: ProtocolAType) -> ProtocolAType
}
This is peculiar. It is not a valid protocol.
If you mean that parameter and return type of methodA is dictated by the caller, then it is this
protocol ProtocolA {
...
func methodA<T>(param1: T) -> T
}
which you can already put in a collection.
If you mean that the parameter and return type of methodA is dictated by the conformer?
extension ProtocolA {
associatedtype ProtocolAType
func description()
func methodA(param1: ProtocolAType) -> ProtocolAType
}
This is a bona fide Protocol with Associated Type (PAT).
Currently, any PATs requires you to use the same concrete type. Because, allowing things like CustomCollection<ProtocolA> would also allow you to use instances conforming to ProtocolA with different associate types
let collection: CustomCollection<ProtocolA> = [StructA(), StructB()]
It is problematic because things like
for item in collection {
item.methodA(2)
}
already can't work. We don't know the type of ProtocolAType at collection[0]. It can be Int. It can also be something else.
There seems to be pitches here and there about improving this like adding syntax to specify the associated type, lifting the constraints and disallowing anything that use associated type, etc.
As is, you can only use concrete types for PAT, not a boxing like normal protocol. So you can use concrete type.
var a: CustomCollection<StructA> = [ ... ]
var b: CustomCollection = [ StructA(...), StructA(...) ] // Let the type be inferred to `StructA`
and if you need to pass it around, you can use generic.
func foo<T>(value: CustomCollection<T>) where T: ProtocolA, T.ProtocolAType == String { ... }
PS
You can edit the post directly rather than adding the edited version beneath. It's probably easier to read that way.