I agree, the currently running OS seems like the right default here. Progressive disclosure and ease of prototyping are good motivations here. If I just want to quickly prototype something, I'm not going to be thinking about choosing a minimum OS; I'm just going to write something using the APIs that are available on my current one. If I decide to distribute that later, *that's* when I'm going to start thinking about minimums (and adding availability directives, if needed).
On Mon, Nov 27, 2017 at 4:53 PM William Dillon via swift-dev < swift-dev@swift.org> wrote: > It would be my assumption that it would build for the currently running > OS. It would be very confusing to me to have availability checks failing > for an OS version lower that what I'm using. I'm sure that I would be > swearing for a few hours before I finally found the obscure documentation > that said that it would compile for the oldest OS swift supports. > > Thanks for asking us! :) > > - Will > > > On Nov 27, 2017, at 4:44 PM, Jordan Rose via swift-dev < > swift-dev@swift.org> wrote: > > Hi, all. Consider the following command, as run on a Mac with an > up-to-date Xcode installed: > > xcrun swiftc foo.swift > > > The question: should this build for the *current running OS,* or *the > oldest macOS Swift supports* (10.9)? You can always specify the > deployment target OS version explicitly with the -target option, but what > should the default behavior be? > > Some points to consider: > - The deployment OS affects availability checks, which means that the > command might succeed on one host but fail on another. > - …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). > - Clang defaults to the current running OS (as of a few Xcodes ago, IIRC). > > 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? > > 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. > > Thanks for your feedback! > Jordan > > P.S. For Apple folks, this is rdar://problem/29948658. > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev > > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
