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

[Erica Sadun]

> On May 13, 2016, at 1:42 AM, Patrick Smith <pgwsmith at 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".