> On Sep 28, 2016, at 11:40 AM, Goffredo Marocchi <[email protected]> wrote:
>
>
>
> Sent from my iPhone
>
> On 28 Sep 2016, at 17:51, Douglas Gregor via swift-evolution
> <[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)
>>
>>> - 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.
I’m sure we can find a reasonable solution to this that doesn’t incur a
significant runtime penalty, e.g., by teaching the runtime conformance
specialization machinery to handle a “redirecting” specialization that maps
from the requirements of the older (more specialized) version to the
requirements of the newer (less specialized) version.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
