A fundamental problem is, how do we get rid of associatedtype duplicates? A pedantic approach is to add trait operations for conformances:
protocol Constructible { associatedtype Value init(_ value: Value) } struct MyStruct { conformance Constructible { rename associatedtype ValueInt = Value } conformance Constructible { rename associatedtype ValueString = Value } typealias ValueInt = Int // or can be inferred init(_ value: Int) typealias ValueString = String // or can be inferred init(_ value: String) } This way, if there is a if there is a conflicting member, which does not use any of the associated types, like func foo(), then we can give it different meanings in different conformances. Although this approach is the most clean one from theoreticall point of view, choosing different names for associated types would not look very good in practise. One possible solution is to *always* automatically match associatedtypes, without using typealiases. protocol ConstructibleFromBoth { associatedtype First associatedtype Second init(first: First) init(second: Second) } struct MyStruct : ConstructibleFromBoth { init(first: Int) init(second: Double) } extension MyStruct { init(first: String) // now there are 2 distinct conformances } extension MyStruct { init(second: Float) // now there are 4 distinct conformances } It introduces another potentially exponential algorithm for compiler. Although, does it? During a conformance test in some generic function, compiler will need to only find the first match or two. Anyway, I guess, people would prefer to state explicitly that a type conforms to multiple versions of a protocol. Attempt #3. We can resolve the conflict between associated types, if we delete (if trait sense) confliting associated types from the type. But with extensions, all associated types can be made conflicting. So there needs to be some attribute, marking, which of the associated types we don’t want. It can lie at the place of conformance: struct MyStruct { }extension MyStruct : @dontCreateTypealiases (Constructible where Value == Int) { ... }extension MyStruct : @dontCreateTypealiases (Constructible where Value == String) { ... }// MyStruct.Value.self // error, no such type struct NormalConformanceTest : Constructible { init(_ value: Float) }NormalConformanceTest.Value.self //=> Float Or we can let constrained protocols syntax carry this attribute by default: extension MyStruct : (Constructible where Value == Int) { ... }// MyStruct.Value.self // error, no such type struct NormalConformanceTest: Constructible { init(_ value: Float) }NormalConformanceTest.Value.self //=> Float The only thing left to solve is generic protocol declaration syntax and protocol specialization syntax. I’d like to present two ways to do this. First, taking ideas from Rust: protocol ContainsCollection<Element> { associatedtype CollectionType : Collection where CollectionType.Element == Element func collection() -> CollectionType } extension String : ContainsCollection<Character>, ContainsCollection<UnicodeScalar>, ContainsCollection<CChar> { func collection() -> CharacterView func collection() -> UnicodeScalarView func collection() -> ContiguousArray<CChar> } Generic parameters are used to disambiguate between different conformances, and associated types are just matched. Explicit typealias specifiction is prohibited, because conflicts. Second, without modifying current protocol declaration syntax: protocol ContainsCollection { associatedtype Element associatedtype CollectionType : Collection where CollectionType.Element == Element func collection() -> CollectionType } extension String : ContainsCollection<Element: Character>, ContainsCollection<Element: UnicodeScalar>, ContainsCollection<Element: CChar> { func collection() -> CharacterView func collection() -> UnicodeScalarView func collection() -> ContiguousArray<CChar> }
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution