[swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

[Erica Sadun]

> On May 12, 2016, at 7:30 PM, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On May 10, 2016, at 2:49 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0075: Adding a Build Configuration Import Test" begins now and runs through May 16. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md
>> 
>> * What is your evaluation of the proposal?
> 
> The goal is valid, but I do have an issue with the 'canImport'. In my world it's not because you can import something that you want to use it. So for conditional compile code, I see this more as a 'didImport'. 
> 
> Unfortunately for the conditional import, since I'm on the page of it's not because you can, that you should; I think it better serve by checking against the os() or arch(). Though, there is a need to ask to import something that might not exist; will this require both 'canImport' and 'didImport', or should we, along my 'didImport', include a 'weakImport/quietImport/importIfExist' which ignores failure to import?


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