<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md</a>]</div><div class=""><br class=""></div><div class="">Hi, David, Michael, Joe. I'm sorry to admit I <i class="">haven't</i> 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.)</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">(sorry for opening the Pandora's Box of "I should be able to introspect types in the libraries I use" again)</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>