[swift-evolution] [Draft] Allow multiple conformances to the same protocol

[Антон Жилин]

A problem with my solution is that there is a conflict between
associatedtype declarations inherited from From<Int> and From<Double>.
Or in your example, associatedtype Element = Int  and  associatedtype
Element = String  are in conflict.
Another example:

protocol Computer {
    associatedtype Internal
    mutable func prepare() -> Internal
    mutable func compute(input: Internal)
}

extension MyType : Computer<Int> { }
extension MyType : Computer<Double> { }

func test<T: Computer>(input: inout T) {
    let internal: T.Internal = input.prepare()
    input.compute(internal)
}

What is T.Internal , Int or Double? I showed the problem very eplicitly,
but it would exist hidden in a much greater number of cases.

It's not that such resolution is impossible, but solution of Chris does not
have this problem at all: generic types do not create associated type
requirements.
In this case, there is no ambiguity:

protocol Computer<Internal> {
    mutable func prepare() -> Internal
    mutable func compute(input: Internal)
}

extension MyType : Computer<Int> { }
extension MyType : Computer<Double> { }

func test<I, T: Computer<I>>(input: inout T) {
    let internal: I = input.prepare()
    input.compute(internal)
}

test(MyType() as Computer<Int>)  // no ambiguity
test(MyType() as Computer<Double>)  // no ambiguity

- Anton

2016-06-09 17:25 GMT+03:00 Vladimir.S <svabox at gmail.com>:

> I like the idea as associatedtype is playing the role of generic type and
> in extension we conforms to the protocol with some specific generic type as
> associated type.
>
> I mean the first idea probably could be
> protocol From<T> {
>      init(_ value: T)
>  }
> but "protocols do not allow generic parameters; use associated types
> instead", so it seems natural to express concrete type as associated type
> for protocol in generic syntax <Type>
>
> Probably alternative syntax could look like:
>
> extension Int : From where .FromType = Float { }
>
> Also, it seems like this proposal could help to solve a problem with the
> same name of associated type in different protocols:
>
> protocol One {
>      associatedtype Element
>      func foo(t: Element)
>  }
>
> protocol Two {
>      associatedtype Element
>      func bar(t: Element)
>  }
>
> struct OneTwo : One, Two {
>     func foo(t: Int) {}
>     func bar(t: String) {}
> }
> // type 'OneTwo' does not conform to protocol 'Two'
> // candidate has non-matching type '(t: String) -> ()' [with Element =
> Element]
>
> So, as I understand, will be possible
> struct OneTwo : One, Two<String> {
>     func foo(t: Int) {} // OneTwo.Element will be Int
>     func bar(t: String) {}
>
> }
>
> On 08.06.2016 22:07, Антон Жилин via swift-evolution wrote:
>
>> ==Motivation==
>>
>> protocol From {
>>     associatedtype FromType
>>     init(_ value: FromType)
>> }
>>
>> The problem is, one type cannot implement multiple From "conversions".
>>
>> ==Proposed solution==
>>
>> Allow specifying all associated types using generic syntax.
>>
>> extension Int : From<Float> { }
>> extension Int : From<Double> { }
>>
>> This is only allowed in conformance declarations.
>>
>> ==Future directions==
>>
>> We can replace all *Convertible protocols with From and Into, which will
>> be
>> defined similarly to Rust.
>>
>> - Anton
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160609/c3dca7a7/attachment.html>