<commit_before># Adding a Build Configuration Import Test

* Proposal: [SE-0075](0075-import-test.md)
* Author: [<NAME>](http://github.com/erica)
* Status: **Active review: May 10...16, 2016**
* Review manager: [<NAME>](http://github.com/lattner)

## Introduction

Expanding the build configuration suite to test for the ability to import certain 
modules was [first introduced](http://article.gmane.org/gmane.comp.lang.swift.evolution/7516/match=darwin)
on the Swift-Evolution list by <NAME>. Although his initial idea (checking for Darwin
to differentiate Apple targets from non-Apple targets) proved problematic, developers warmly
greeted the notion of an import-based configuration test. 
<NAME> wrote, "There's a direction that we want to move to a unified name for the libc module for all platform, so 'can import Darwin' might not be a viable long-term strategy." 
Testing for imports offers advantages that stand apart from this one use-case: to test for API availability before use.
 
## Motivation

Swift's existing set of build configurations specify platform differences, not module commonalities. For example, UIKit enables you to write view code supported on both iOS and tvOS. SpriteKit allows common code to render on OS X, iOS, and tvOS that would require an alternate UI on Linux. Testing for Metal support or Media Player would guard code that will not function on the simulator. If the simulator adopted these modules at some future time, the code would naturally expand to provide compatible execution without source modification.

```
#if canImport(UIKit)
   // UIKit-based code
   #elseif canImport(Cocoa)
   // OSX code
   #elseif
   // Workaround/text, whatever
#endif
```

Guarding code with operating system tests can be less future-proofed than testing for module support.  Excluding OS X to use UIColor creates code that might eventually find its way to a Linux plaform. Targeting Apple platforms by inverting a test for Linux essentially broke after the introduction of `Windows` and `FreeBSD` build configurations:

```
// Exclusive os tests are brittle
#if !os(Linux)
   // Matches OSX, iOS, watchOS, tvOS, Windows, FreeBSD
#endif
```

Inclusive OS tests (if os1 || os2 || os3...) must be audited each time the set of possible platforms expands. <commit_msg>Added SE-0075 review thread link<commit_after># Adding a Build Configuration Import Test

* Proposal: [SE-0075](0075-import-test.md)
* Author: [<NAME>](http://github.com/erica)
* Status: **Active review: May 10...16, 2016**
* Review manager: [<NAME>](http://github.com/lattner)

## Introduction

Expanding the build configuration suite to test for the ability to import certain 
modules was [first introduced](http://article.gmane.org/gmane.comp.lang.swift.evolution/7516/match=darwin)
on the Swift-Evolution list by <NAME>. Although his initial idea (checking for Darwin
to differentiate Apple targets from non-Apple targets) proved problematic, developers warmly
greeted the notion of an import-based configuration test. 
<NAME> wrote, "There's a direction that we want to move to a unified name for the libc module for all platform, so 'can import Darwin' might not be a viable long-term strategy." 
Testing for imports offers advantages that stand apart from this one use-case: to test for API availability before use.

[Swift Evolution Review Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/16620)
 
## Motivation

Swift's existing set of build configurations specify platform differences, not module commonalities. For example, UIKit enables you to write view code supported on both iOS and tvOS. SpriteKit allows common code to render on OS X, iOS, and tvOS that would require an alternate UI on Linux. Testing for Metal support or Media Player would guard code that will not function on the simulator. If the simulator adopted these modules at some future time, the code would naturally expand to provide compatible execution without source modification.

```
#if canImport(UIKit)
   // UIKit-based code
   #elseif canImport(Cocoa)
   // OSX code
   #elseif
   // Workaround/text, whatever
#endif
```

Guarding code with operating system tests can be less future-proofed than testing for module support.  Excluding OS X to use UIColor creates code that might eventually find its way to a Linux plaform. Targeting Apple platforms by inverting a test for Linux essentially broke after the introduction of `Windows` and `FreeBSD` build configurations:

```
// Exclusive os tests are brittle
#if !os(Linux)
   // Matches OSX, iOS, watchOS, tvOS, Windows, FreeBSD
#endif
```

Inclusive OS tests (if os1 || os2 || os3...) must be audited each time the set of possible platforms expands. 
{'fraction_non_alphanumeric': 0.07497337593184239, 'fraction_numerical': 0.011714589989350373, 'mean_word_length': 4.531213191990577, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1658667', 'n_tokens_mistral': 1299, 'n_tokens_neox': 1200, 'n_words': 620}