> On Apr 3, 2017, at 11:55 AM, Jordan Rose <[email protected]> wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md>] > > Hi, David, Michael, Joe. I'm sorry to admit I haven't been keeping up with > all the discussion on this proposal, but I do want to ask a very important > implementation question: how will key paths be represented? Specifically, I'm > concerned about it possibly using reflection metadata, which contributes to > both code size bloat and secrecy leaks. (Imagine the metadata for a property > 'shouldConnectToDishwasherOSDevice" appearing in a new build of the iOS > simulator.) > > I can imagine a very simple but inefficient implementation strategy that's > based around something like closures, and a more efficient one that would > directly code-generate offsets for structs (and use symbolic offsets when > doing cross-module generation). Both of these would sidestep the use of > reflection metadata. Is that more what you were thinking?
I was planning to use direct offsets when they're knowable, and fall back to reflection when genericity or resilience gets in the way. In the case when we're accessing a property resiliently, we'd need to use accessors as a fallback anyway, so if the reflection metadata isn't there, you'd end up with a computed property access. -Joe
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
