[swift-evolution] [swift-evolution-announce] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Joe Groff]

> On Apr 3, 2017, at 11:55 AM, Jordan Rose <jordan_rose at apple.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170403/4eef6e32/attachment.html>