> On Sep 28, 2016, at 1:23 PM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> 
>> On Sep 28, 2016, at 9:51, Douglas Gregor <dgre...@apple.com 
>> <mailto: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.)

Done in the updated form of this proposal.

> 
>> 
>>> - 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?)

Dynamically looking up witness tables isn’t cheap. Still, we’ll find the right 
tradeoff here.

        - Doug


_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to