[swift-evolution] [Proposal draft] Conditional conformances

Douglas Gregor dgregor at apple.com
Wed Sep 28 15:26:24 CDT 2016


> On Sep 28, 2016, at 1:23 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Sep 28, 2016, at 9:51, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>> 
>> 
>>> On Sep 27, 2016, at 5:06 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160928/262f9016/attachment.html>


More information about the swift-evolution mailing list