<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><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=""><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="">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</span></div></blockquote></div><div class=""><br class=""></div><div class="">I'm keenly interested in custom importers, if only because I would love to treat storyboards and asset catalogs as "languages" and automatically generate typesafe enums for their various stringly-typed identifiers. (Note to anyone in the peanut gallery getting excited: I don't work at Apple and can't make this a part of the toolchain; I just hope they'd do it if they could.)</div><div class=""><br class=""></div><div class="">But at the same time, I have a hard time seeing that as a great solution for dynamic languages. I've barely used Python, but I work in Ruby on Rails a lot, and Rubyists rely pretty heavily on dynamic features. For instance, the ActiveRecord ORM creates all its accessors on demand through Ruby's `method_missing` feature. Static analysis would be useless for this, and I can't imagine that profile-based analysis would be very reliable. Even the F# Type Providers documentation warns that "You should avoid writing a type provider where a schema isn't available."</div><div class=""><br class=""></div><div class="">A dynamic dispatch feature, on the other hand, could reliably reproduce Ruby's behavior because every method call would simply be dispatched through Ruby's method-calling machinery, just as a method call in Ruby would be. It's a round hole for the round peg of a dynamic language's dispatch behavior to fit into. Other languages, like Objective-C and C++, could use the square hole of a custom importer.</div><div class=""><br class=""></div><div class="">Or maybe the right custom importer design could have it both ways, allowing dynamic languages to accept and write a dispatch for unknown methods, while permitting static languages to match against the more specific data they have available. I don't know. All I'm saying is, static languages and dynamic languages are different, and we need the features necessary to support both without making either of them worse. It's quite possible that the best design for static language bridges will look very, very different from the best design for dynamic languages.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></body></html>