Sent from my iPhone
> On 28 Sep 2016, at 17:51, Douglas Gregor via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Sep 27, 2016, at 5:06 PM, Jordan Rose <jordan_r...@apple.com> wrote:
>>
>> Great job thinking this all through (as usual), and I’ll be very happy to
>> have Optional and Array become Equatable. Here’s some of my thoughts on the
>> library evolution aspect of this:
>>
>> - Removing a conditional conformance isn’t allowed, obviously.
>> - Adding a conditional conformance is just like adding an unconditional
>> conformance—it needs availability info.
>
> Right. The main wrinkle I see here is that, when you add a conditional
> conformance, you will effectively end up with overlapping conformances when
> running an old application against a new library. Do you want me to capture
> these cases in the proposal in a section on “Resilience” or “Library
> Evolution”, like I’ve tried to capture the effect on ABI Stability? (I think
> that makes sense)
>
>> - It would be nice™ if making a conditional conformance more general was
>> allowed. Since the plan doesn't allow overlapping conformances, I think this
>> is actually implementable: just don’t put the constraints in the symbol
>> name. I don’t know how to represent the backwards-deploying aspects of this
>> right now, so it probably makes sense to forbid it today, but I think it
>> would be nice if the implementation left the door open.
>
> Yeah. It’s a different set of witness tables that one would need to gather to
> use the conditional conformance in the newer version of the library vs. in an
> older version of a library. That’s okay if we leave the
> witness-table-gathering to the runtime, but not so great if we statically
> provide the witness tables.
>
Would this be a case in which the win by having this feature and letting the
runtime gather the witness tables offset the losses from doing his operations
at runtime? I would like to think that in cases like this there is at least the
option to opt for more flexibility.
>
>> On that note, what happens here?
>>
>> // Module Lib
>> public protocol Base {}
>> public protocol Sub: Base {}
>> public protocol Special: Sub {}
>>
>> public struct Impl<T> {}
>> extension Impl: Special where T: Special {}
>>
>>
>> // Module Client
>> import Lib
>>
>> extension Impl: Sub where T: Sub {}
>>
>> I think this gets rejected because Impl already has a conformance to Sub—the
>> extension in Client, despite being less specialized, shows up too late to
>> actually declare this conformance “better”. Is that correct?
>
> Correct. Impl has a conformance to ‘Sub’ in Lib; Client cannot declare a new
> one, because it overlaps. Had all of this code been in one module, it would
> be well-formed, because the implied conformance to ’Sub’ in the first
> extension would lose to the explicit conformance to Sub in the second
> (less-specialized) extension.
>
> - Doug
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
