on Sun Oct 02 2016, Brent Royal-Gordon <[email protected]> wrote:
>> On Oct 1, 2016, at 8:45 AM, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >>> I’m up for reviving the ObjectiveCBridgeable proposal :) >> >> Okay, but IMO the API of that protocol is wrong. Any public interface >> should look something like _CustomObjectiveCBridgeable per >> > https://github.com/apple/swift/commit/87944ed2449ec7314ed8690b8894ce96ad339ebf#diff-9b6ea5442068d139aa4193a59b6e4b91 > > Do you mind providing some color on this design? It seems to me that > the proposal's ObjectiveCBridgeable design was both more idiomatic How so? > and permitted more behavior (particularly by allowing lazy collection > bridging), whereas this design's only benefit seems to be that it > abstracts away the specific "policy" (but that would prevent lazy > bridging or other behavior differences between different > policies). Why is this one better? Because it results in far less code repetition and far more predictable semantic relationships among the different bridging operations. Yes, to agree with that design one has to buy into the idea that lazily bridging from Objective-C is a net loss, and that any important cases where it's a win can be dealt with well. There are many strong reasons to believe that's true, but we have some work ahead of us in order to demonstrate it conclusively. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
