I think you'll still have to write the availability checks, because Swift will make you. I think the fixit also tells you what you need for the API you're trying to use. The confusing thing will be, though, that it'll use the fall-back path unless you explicitly set the target version.
> On Nov 28, 2017, at 10:36 AM, Tony Allevato via swift-dev > <swift-dev@swift.org> wrote: > > 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 <mailto: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 >> <mailto: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 <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >> <https://lists.swift.org/mailman/listinfo/swift-dev> > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org <mailto:swift-dev@swift.org> > https://lists.swift.org/mailman/listinfo/swift-dev > <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
