> On Sep 28, 2016, at 9:51, Douglas Gregor <dgre...@apple.com> wrote:
>
>
>> On Sep 27, 2016, at 5:06 PM, Jordan Rose <jordan_r...@apple.com
>> <mailto: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)
Sure, yes please. (I think the main point is that the "conditional" doesn't
make a difference here.)
>
>> - 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.
This confuses me. Why aren't we just using the minimal (unconditional)
conformance representation, and then pulling the associated type witness tables
out dynamically? Is that significantly more expensive? (Am I just missing
something?)
>
>
>> 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.
Thanks!
Jordan
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
