<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="">Hi, all. Consider the following command, as run on a Mac with an up-to-date Xcode installed:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">xcrun swiftc foo.swift</div></blockquote><div class=""><br class=""></div>The question: should this build for the <i class="">current running OS,</i> or <i class="">the oldest macOS Swift supports</i> (10.9)? You can always specify the deployment target OS version explicitly with the -target option, but what should the default behavior be?<div class=""><br class=""></div><div class="">Some points to consider:</div><div class="">- The deployment OS affects availability checks, which means that the command might succeed on one host but fail on another.</div><div class="">- …but we already changed the default for the interpreter (`xcrun swift`) to be the current running OS in Swift 3.1 (Xcode 8.3, last spring).</div><div class="">- Clang defaults to the current running OS (as of a few Xcodes ago, IIRC).</div><div class=""><br class=""></div><div class="">Given these points, I'm inclined to change swiftc to default to building for the current running OS when no target is specified, but what do other people think?<br class=""><div class=""><div class=""><br class=""></div><div class="">Note that this doesn't apply to projects built with either Xcode or the Swift Package Manager, both of which always explicitly provide a deployment target. Invoking swiftc directly and not providing -target means (1) you are definitely compiling for Mac (when run on a Mac), and (2) there's a good chance you don't plan to distribute what you just built, because until Swift lives in the OS, it has dependencies on your installed Swift toolchain (currently messily resolved with absolute rpaths). If you avoid this with -static-stdlib, you're giving up the ability to have dynamic libraries, because we didn't implement that properly.</div></div></div><div class=""><br class=""></div><div class="">Thanks for your feedback!</div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. For Apple folks, this is <a href="rdar://problem/29948658" class="">rdar://problem/29948658</a>.</div><div class=""><br class=""></div></body></html>