Sent from my iPhone
> On 28 Sep 2016, at 19:45, Douglas Gregor <dgre...@apple.com> wrote:
>
>
>> On Sep 28, 2016, at 11:40 AM, Goffredo Marocchi <pana...@gmail.com> wrote:
>>
>>
>>
>> Sent from my iPhone
>>
>>> On 28 Sep 2016, at 17:51, Douglas Gregor via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>>
>>>> On Sep 27, 2016, at 5:06 PM, Jordan Rose <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)
>>>
>>>> - 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
>
Very glad to hear that Doug :).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
