[swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test
erica at ericasadun.com
Thu May 12 20:50:28 CDT 2016
> 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:
>> * 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:
and you test at the use-site
// use things that are available in x
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.
More information about the swift-evolution