> On Sep 28, 2016, at 1:23 PM, Jordan Rose <[email protected]> wrote:
>
>
>> On Sep 28, 2016, at 9:51, Douglas Gregor <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Sep 27, 2016, at 5:06 PM, Jordan Rose <[email protected]
>>> <mailto:[email protected]>> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
