> On May 13, 2016, at 1:42 AM, Patrick Smith <pgwsm...@gmail.com> wrote: > >> canImport (or whatever it ends up being called) is deliberate. >> >> You test before you import: >> >> #if canImport(x) >> import x >> #else >> ... >> #endif >> >> and you test at the use-site >> >> #if canImport(x) >> // use things that are available in x >> #else >> ... >> >> So you don't import UIKit unless you *can*, and you don't use UIColor unless >> you can import UIKit. This follows closely on the design of __has_include. >> >> -- E > > > I guess one issue I can see is it’s used in two different ways: > - The first use of canImport is used to check whether it can import a module, > and then does so, but there’s no requirement for it to do so. Is this the > right this to do? > - The second use of canImport makes no guarantee that the module has been > imported, only that it can. > > What if instead `import` could return whether it imported or not, when used > with #if? Instead of ‘can import’, you get ‘did just import’ and ‘has > imported’.
That would be a much more complicated proposal than this simple build configuration test. > As per Pyry’s feedback, you could add a version: > > #if import Frobnication(<1.7.3) // <- Only added version constraint here. > extension Knob : Frobnicatable { ... } > #endif I have no problem with this but would need to defer to the build and language people to determine whether that's practical in today's Swift. Right now, there's a major-version mention in build packages but I'm not sure whether that information then propagates in a usable way. If it's possible, then yes, I'd rather add it in the initial design than as a later addition and I can extend Pyry's suggestion in "Future Directions". I've cc'ed in Daniel Dunbar to see if he has anything specific to add about this. -- E p.s. Also on my Swift Bucket list: "import as". _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution