<div dir="ltr">Importing the right version of a module (such as the standard library) when more than one are available is just a search-paths problem. Supporting multiple versions of the language's syntax and ABI, though, as far as I can tell, requires the switch to be deeply baked into the compiler.<div><br></div><div>So I don't really see how we can get away with a "general" solution, beyond perhaps some SwiftPM support for libraries that provide source or binaries for multiple language versions.<div><div class="gmail_extra">
<br><div class="gmail_quote">On Wed, Aug 3, 2016 at 12:44 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Aug 3, 2016, at 1:16 AM, Brent Royal-Gordon via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:<br>
><br>
>> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> • a top-of-file "shebang"-style comment indicating the version, something like //#swift(4), mirroring the "#if swift" syntax<br>
><br>
> `import Swift 3.1`?<br>
><br>
> I think this brings up two interesting questions:<br>
><br>
> * Do we want to be able to mix files using different versions of Swift in the same module?<br>
<br>
</span>No. It simplifies the problem greatly if the whole module is compiled with a single Swift version.<br>
<span class=""><br>
> * Do we want to extend these backwards compatibility features beyond the standard library to other modules?<br>
<br>
</span>If we can design generally-useful features for handling language versioning, that the standard library can adopt, that would be great.<br>
<br>
- Doug<br>
<br>
</blockquote></div><br></div></div></div></div>