<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 11, 2017, at 10:17 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div dir="auto" class=""><div class="">so I don't think there's a time constraint forcing us to consider the "narrow" vs "huge" dimension. What's the best thing for the language and tools in the long term? This is a feature that influences the semantics of potentially any call site in all Swift code, which we'd have to live with forever if we accepted it now. Opening up the compiler architecture to make custom importers easier to write is a great solution to a ton of problems, including yours I think, without adding complexity to the core language. Experience in .NET land seems to show it's a great technique for integrating dynamic systems with static type systems, without poking unnecessary holes in the static language's type system</div></div></div></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div><div class="">As I mentioned, I’m not familiar with F# type providers. As I told you upthread, I will read about them and respond with an informed opinion when I have time.</div></div></div></blockquote><br class=""></div><div>I have done some quick reading about type providers, but I am certainly not an expert. I have a couple of questions that I’d appreciate your insight on:</div><div><br class=""></div><div>Type providers seem like a (complicated!) compile-time form of meta programming or compiler plugin. How does this help interoperability with dynamic languages, where the preponderance of values have types that are not knowable at compile time?</div><div><br class=""></div><div>To pick a specific example you are familiar with, this seems like it could help in theory (though I suspect it would be be entirely impractical in practice) to provide types for Objective-C methods that are coming from an SDK where you have declarations. </div><div><br class=""></div><div>In contrast, it does *not* seem like it would help with the problem of resolving members of “id” typed values in Objective-C, which is the crux of the dynamic language problem. If my understanding is correct, type providers seem completely unhelpful for python interoperability, because you don’t know the types of python values: anything loaded from a Python property or returned by a Python function is the equivalent of “id”.</div><div><br class=""></div><div>It’s entirely possible I’m missing something big. If so, I’d appreciate a pointer to something to read that explains how this works. Thanks!</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></body></html>