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

Gwendal Roué gwendal.roue at gmail.com
Fri May 13 03:54:31 CDT 2016


Hello,

`#if import Foo` can not deal with the fact that a single source file may have to perform the importability test several times.

For example:

	#if canImport(UIKit)
		import UIKit
		// Some UIKit-related declarations
	#endif
	// Later in the same file
	func f() {
		#if canImport(UIKit)
			// Use UIKit-only declarations
		#endif
	}

I know, I know, some will tell me to refactor my code. So let's just say I'm prototyping and that the code doesn't have its final shape, OK?

Still, testing for module importability is not the same as importing it.

Gwendal Roué

> Le 13 mai 2016 à 10:40, Pyry Jahkola via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Patrick,
> 
> I think you're making valuable points here. I also can't think of cases where you wouldn't also import a module in case it was found to be importable. So the use cases I can think of could as well be tackled by allowing expressions such as `import Foo.Bar` as compile-time checks within the conditions of `#if` like you suggested. That would bring those libraries only visible within the scope of that block.
> 
> However, there can be cases where you're considering importing more than one module, so something like:
> 
>     #if import Foo, import Bar
>       ...
>     #elseif import Baz
>       ...
>     #endif
> 
> should be considered in that design too. And I don't like the fact that it would import many modules in one line of code.
> 
> However, I don't get your concerns of "whether already imported or not". Isn't `import` strictly about bringing identifiers of linked libraries visible in the current file and not about linking to libraries in code.
> 
> — Pyry
> 
>> 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’.
>> 
>> 
>> import Required // Error if not present, current behaviour
>> 
>> #if import CoolThing // Skips code block if not present, imports otherwise
>>  // Do something with CoolThing module
>> #else
>>  import AlmostAsCoolThing
>> #endif
>> 
>> and you test at the use-site
>> 
>> #if module(X) // Does not import, only checks if it has been imported
>>  // use things that are available in X
>> #else
>> 
>> 
>> 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
>> 
>> 
>> 
>> Just a way to make it less low level.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/3c039006/attachment.html>


More information about the swift-evolution mailing list