[swift-evolution] [Draft] Adding a Build Configuration Import Test
pierremonodbroca at gmail.com
Wed Mar 23 01:59:16 CDT 2016
My guess is most often one will want to import exactly what one is testing (Brent example) but I guess it would be very handy to do something like
import Foo.Bar as FooBar
In this case both form would be relevant.
Also +1 on Haraviks point:
> My only question is whether there should be a way to test minimum module versions? If I add support for a module but target a particularly recent version then that support won’t compile for platforms with older versions of the same module, so I should be able to prevent them from being a match.
> Le 23 mars 2016 à 05:28, Erica Sadun via swift-evolution <swift-evolution at swift.org> a écrit :
> I'm preparing a separate platform proposal. I want to make clear that the intent is to use the
> framework being tested. However, the test that does the import may be separated from the code
> that uses the framework, which is why the call does not import.
> -- E
>>> On Mar 22, 2016, at 10:24 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>>> #if canImport(UIKit)
>>> // UIKit-based code
>>> #elseif canImport(Cocoa)
>>> // OSX code
>>> // Workaround/text, whatever
>> My question is simple: Are there cases where you want to test if you can import something, but you don't want to *actually* import it? If not, should we perhaps just do this?
>> #if import UIKit
>> // UIKit-based code, has UIKit available
>> #elseif import Cocoa
>> // OS X code, has Cocoa available
>> // Fallback
>> Brent Royal-Gordon
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution