<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 7:02 AM, Joe Groff 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 6:12 PM, Slava Pestov 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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 6:10 PM, Matthew Johnson 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=""><span 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; float: none; display: inline !important;" class="">Setting this aside, I’m very curious to hear whether type providers influence your thinking after you’ve had a chance to look into them. I have always thought they were very cool.</span></div></blockquote></div><br class=""><div class="">I’m in favor of solving this problem with something like type providers also. The required compiler changes would be significant but would also clean up the interface between the ClangImporter, Sema and Serialization. If done right it would be a net gain that would benefit all users, instead of just adding YetAnotherCornerCase™ that makes implementation maintainers curse and scream.</div></div></div></blockquote><br class=""></div><div class="">I find it ironic that you’re talking pejoratively about a feature that has very narrow impact, complaining about how much of an impact on the compiler it would have, and then pine for a hugely invasive feature - one that would cause a ton of code churn, and probably wouldn’t actually be enough to eliminate the special cases in place because of ObjC interop.</div></div></blockquote><div class=""><br class=""></div><div class="">You underestimate the impact this would have on function call type checking, but since this is an additive, non-ABI-stability feature, I have trouble considering it a candidate for Swift 5, </div></div></div></blockquote><div><br class=""></div><div>The guidelines for Swift 5 are publicly documented here:</div><div><a href="https://github.com/apple/swift-evolution/blob/master/README.md#evolution-process-for-swift-5" class="">https://github.com/apple/swift-evolution/blob/master/README.md#evolution-process-for-swift-5</a></div><div><br class=""></div><div>This is relevant and seems reasonable to me:</div><div><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box; margin-top: 0.25em;" class=""><p style="box-sizing: border-box; margin-top: 16px; margin-bottom: 16px;" class=""><span style="box-sizing: border-box; font-weight: 600;" class="">Syntactic additions</span>. Syntactic changes do not increase the expressive power of the language but do increase its complexity. Consequently, such changes must be extremely well-motivated and will be subject to additional scrutiny. We will expect proposals to include concrete data about how wide spread the positive impact will be.</p></li></ul><div class=""><br class=""></div><div class="">I explicitly point out that this is a sugar change.</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><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=""></div><div>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><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>