> On May 13, 2016, at 1:42 AM, Patrick Smith <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
