# \_\_swift\_\_

**URL:** <https://forums.swift.org/t/swift/3853>\
**Category:** Compiler\
**Created:** [August 24, 2016, 10:57pm UTC](https://forums.swift.org/t/swift/3853 "2016-08-24T22:57:27Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [August 24, 2016, 10:57pm UTC](https://forums.swift.org/t/swift/3853/1 "2016-08-24T22:57:27Z")

</div>

Hey, all. I’m here to propose predefining a macro \_\_swift\_\_ when C code is compiled with Swift. We’ve gotten a few requests for it in the past and haven’t done it so that people don’t write header files that arbitrarily restrict features when used from Swift, or check for "Swift" when they really should be checking for modules support, or Objective-C mode, or nullability support. (Or worse, they guard code under \_\_swift\_\_ and then don’t ever test it, leading to failures to import the module from Swift.)

However, with Swift 3, it’s now become important for Objective-C authors to be able to control how their APIs look in modern Swift 3 without disrupting existing clients on Swift 2.3. (Or just because Swift 3 style looks out-of-place in Swift 2.3.) The most obvious way to do this would be to define a macro that has the Swift version in it. For Swift version X.Y.Z, we could use something like

-D\_\_swift\_\_=XYYZZ

e.g.

-D\_\_swift\_\_=30001

for Swift 3.0.1.

This is option (1). Option (2) would be to define \_\_swift\_\_ as a predicate that took version numbers:

-D\_\_swift\_\_(MAJOR, MINOR, PATCH)=(MAJOR \* 10000 + MINOR \* 100 + PATCH \<= XYYZZ)  
-D\_\_swift\_\_(MAJOR, MINOR, PATCH)=(MAJOR \* 10000 + MINOR \* 100 + PATCH \<= 30001)

For completeness’ sake, option (3) would be to define a single macro \_\_SWIFT3\_\_, defined to 1. Clients can test for the presence or absence of this macro. I don’t like this option because (a) Swift 4 will also need to define \_\_SWIFT3\_\_, because it shouldn’t have the “old” behavior, and (b) we might very well want something like this again in the future; will we also define \_\_SWIFT4\_\_?

(Why \_\_swift\_\_ and not \_\_SWIFT\_\_? By analogy with \_\_cplusplus [sic] and \_\_clang\_\_, although not \_\_STDC\_\_ or  
\_\_STDC\_VERSION\_\_. I don’t actually have a strong opinion here.)

Thoughts?  
Jordan

P.S. For Apple folks, this is rdar://problem/26921435 \<rdar://problem/26921435\>.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [August 25, 2016, 4:38pm UTC](https://forums.swift.org/t/swift/3853/2 "2016-08-25T16:38:31Z")

</div>

Option (1) sounds good to me. We don’t need to make this complicated.

- Doug

> **···**
>
> > On Aug 24, 2016, at 3:57 PM, Jordan Rose \<jordan\_rose@apple.com\> wrote:
> > 
> > Hey, all. I’m here to propose predefining a macro \_\_swift\_\_ when C code is compiled with Swift. We’ve gotten a few requests for it in the past and haven’t done it so that people don’t write header files that arbitrarily restrict features when used from Swift, or check for "Swift" when they really should be checking for modules support, or Objective-C mode, or nullability support. (Or worse, they guard code under \_\_swift\_\_ and then don’t ever test it, leading to failures to import the module from Swift.)
> > 
> > However, with Swift 3, it’s now become important for Objective-C authors to be able to control how their APIs look in modern Swift 3 without disrupting existing clients on Swift 2.3. (Or just because Swift 3 style looks out-of-place in Swift 2.3.) The most obvious way to do this would be to define a macro that has the Swift version in it. For Swift version X.Y.Z, we could use something like
> > 
> > -D\_\_swift\_\_=XYYZZ
> > 
> > e.g.
> > 
> > -D\_\_swift\_\_=30001
> > 
> > for Swift 3.0.1.
> > 
> > This is option (1).

---

<div class="post-metadata">

**Author:** ![ddunbar](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ddunbar/32/1933_2.png) [@ddunbar](https://forums.swift.org/u/ddunbar)\
**Post date:** [August 25, 2016, 4:49pm UTC](https://forums.swift.org/t/swift/3853/3 "2016-08-25T16:49:45Z")

</div>

+1

- Daniel

> **···**
>
> > On Aug 25, 2016, at 9:38 AM, Douglas Gregor via swift-dev \<swift-dev@swift.org\> wrote:
> > 
> > > On Aug 24, 2016, at 3:57 PM, Jordan Rose \<jordan\_rose@apple.com \<mailto:jordan\_rose@apple.com\>\> wrote:
> > > 
> > > Hey, all. I’m here to propose predefining a macro \_\_swift\_\_ when C code is compiled with Swift. We’ve gotten a few requests for it in the past and haven’t done it so that people don’t write header files that arbitrarily restrict features when used from Swift, or check for "Swift" when they really should be checking for modules support, or Objective-C mode, or nullability support. (Or worse, they guard code under \_\_swift\_\_ and then don’t ever test it, leading to failures to import the module from Swift.)
> > > 
> > > However, with Swift 3, it’s now become important for Objective-C authors to be able to control how their APIs look in modern Swift 3 without disrupting existing clients on Swift 2.3. (Or just because Swift 3 style looks out-of-place in Swift 2.3.) The most obvious way to do this would be to define a macro that has the Swift version in it. For Swift version X.Y.Z, we could use something like
> > > 
> > > -D\_\_swift\_\_=XYYZZ
> > > 
> > > e.g.
> > > 
> > > -D\_\_swift\_\_=30001
> > > 
> > > for Swift 3.0.1.
> > > 
> > > This is option (1).
> > 
> > Option (1) sounds good to me. We don’t need to make this complicated.
> > 
> > - Doug
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-dev mailing list  
> > swift-dev@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-dev](https://lists.swift.org/mailman/listinfo/swift-dev)

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [August 25, 2016, 9:48pm UTC](https://forums.swift.org/t/swift/3853/4 "2016-08-25T21:48:00Z")

</div>

Okay. Next question: two digits or three digits for the minor and patch versions?

- Two digits: if we ever switch to year/month combinations like C/C++, those will be higher values (unless we get to Swift 20 first).  
- Three digits: better for "fake" versions like 3.0.100.

Jordan

> **···**
>
> > On Aug 25, 2016, at 9:38, Douglas Gregor \<dgregor@apple.com\> wrote:
> > 
> > > On Aug 24, 2016, at 3:57 PM, Jordan Rose \<jordan\_rose@apple.com \<mailto:jordan\_rose@apple.com\>\> wrote:
> > > 
> > > Hey, all. I’m here to propose predefining a macro \_\_swift\_\_ when C code is compiled with Swift. We’ve gotten a few requests for it in the past and haven’t done it so that people don’t write header files that arbitrarily restrict features when used from Swift, or check for "Swift" when they really should be checking for modules support, or Objective-C mode, or nullability support. (Or worse, they guard code under \_\_swift\_\_ and then don’t ever test it, leading to failures to import the module from Swift.)
> > > 
> > > However, with Swift 3, it’s now become important for Objective-C authors to be able to control how their APIs look in modern Swift 3 without disrupting existing clients on Swift 2.3. (Or just because Swift 3 style looks out-of-place in Swift 2.3.) The most obvious way to do this would be to define a macro that has the Swift version in it. For Swift version X.Y.Z, we could use something like
> > > 
> > > -D\_\_swift\_\_=XYYZZ
> > > 
> > > e.g.
> > > 
> > > -D\_\_swift\_\_=30001
> > > 
> > > for Swift 3.0.1.
> > > 
> > > This is option (1).
> > 
> > Option (1) sounds good to me. We don’t need to make this complicated.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [August 25, 2016, 9:58pm UTC](https://forums.swift.org/t/swift/3853/5 "2016-08-25T21:58:46Z")

</div>

I think we can just stick with 2 digits.

&nbsp;&nbsp;- Doug

> **···**
>
> > On Aug 25, 2016, at 2:48 PM, Jordan Rose \<jordan\_rose@apple.com\> wrote:
> > 
> > > On Aug 25, 2016, at 9:38, Douglas Gregor \<dgregor@apple.com \<mailto:dgregor@apple.com\>\> wrote:
> > > 
> > > > On Aug 24, 2016, at 3:57 PM, Jordan Rose \<jordan\_rose@apple.com \<mailto:jordan\_rose@apple.com\>\> wrote:
> > > > 
> > > > Hey, all. I’m here to propose predefining a macro \_\_swift\_\_ when C code is compiled with Swift. We’ve gotten a few requests for it in the past and haven’t done it so that people don’t write header files that arbitrarily restrict features when used from Swift, or check for "Swift" when they really should be checking for modules support, or Objective-C mode, or nullability support. (Or worse, they guard code under \_\_swift\_\_ and then don’t ever test it, leading to failures to import the module from Swift.)
> > > > 
> > > > However, with Swift 3, it’s now become important for Objective-C authors to be able to control how their APIs look in modern Swift 3 without disrupting existing clients on Swift 2.3. (Or just because Swift 3 style looks out-of-place in Swift 2.3.) The most obvious way to do this would be to define a macro that has the Swift version in it. For Swift version X.Y.Z, we could use something like
> > > > 
> > > > -D\_\_swift\_\_=XYYZZ
> > > > 
> > > > e.g.
> > > > 
> > > > -D\_\_swift\_\_=30001
> > > > 
> > > > for Swift 3.0.1.
> > > > 
> > > > This is option (1).
> > > 
> > > Option (1) sounds good to me. We don’t need to make this complicated.
> > 
> > Okay. Next question: two digits or three digits for the minor and patch versions?
> > 
> > - Two digits: if we ever switch to year/month combinations like C/C++, those will be higher values (unless we get to Swift 20 first).  
> > - Three digits: better for "fake" versions like 3.0.100.

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [August 25, 2016, 10:11pm UTC](https://forums.swift.org/t/swift/3853/6 "2016-08-25T22:11:15Z")

</div>

Okay. PR here: [[ClangImporter] Predefine \_\_swift\_\_ in imported (Obj)C code. by jrose-apple · Pull Request #4510 · apple/swift · GitHub](https://github.com/apple/swift/pull/4510/%5C).

Jordan

> **···**
>
> > On Aug 25, 2016, at 14:58, Douglas Gregor \<dgregor@apple.com\> wrote:
> > 
> > > On Aug 25, 2016, at 2:48 PM, Jordan Rose \<jordan\_rose@apple.com \<mailto:jordan\_rose@apple.com\>\> wrote:
> > > 
> > > > On Aug 25, 2016, at 9:38, Douglas Gregor \<dgregor@apple.com \<mailto:dgregor@apple.com\>\> wrote:
> > > > 
> > > > > On Aug 24, 2016, at 3:57 PM, Jordan Rose \<jordan\_rose@apple.com \<mailto:jordan\_rose@apple.com\>\> wrote:
> > > > > 
> > > > > Hey, all. I’m here to propose predefining a macro \_\_swift\_\_ when C code is compiled with Swift. We’ve gotten a few requests for it in the past and haven’t done it so that people don’t write header files that arbitrarily restrict features when used from Swift, or check for "Swift" when they really should be checking for modules support, or Objective-C mode, or nullability support. (Or worse, they guard code under \_\_swift\_\_ and then don’t ever test it, leading to failures to import the module from Swift.)
> > > > > 
> > > > > However, with Swift 3, it’s now become important for Objective-C authors to be able to control how their APIs look in modern Swift 3 without disrupting existing clients on Swift 2.3. (Or just because Swift 3 style looks out-of-place in Swift 2.3.) The most obvious way to do this would be to define a macro that has the Swift version in it. For Swift version X.Y.Z, we could use something like
> > > > > 
> > > > > -D\_\_swift\_\_=XYYZZ
> > > > > 
> > > > > e.g.
> > > > > 
> > > > > -D\_\_swift\_\_=30001
> > > > > 
> > > > > for Swift 3.0.1.
> > > > > 
> > > > > This is option (1).
> > > > 
> > > > Option (1) sounds good to me. We don’t need to make this complicated.
> > > 
> > > Okay. Next question: two digits or three digits for the minor and patch versions?
> > > 
> > > - Two digits: if we ever switch to year/month combinations like C/C++, those will be higher values (unless we get to Swift 20 first).  
> > > - Three digits: better for "fake" versions like 3.0.100.
> > 
> > I think we can just stick with 2 digits.

---

<div class="post-metadata">

**Author:** ![tkremenek](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tkremenek/32/9115_2.png) [@tkremenek](https://forums.swift.org/u/tkremenek)\
**Post date:** [August 27, 2016, 4:48am UTC](https://forums.swift.org/t/swift/3853/7 "2016-08-27T04:48:42Z")

</div>

Thanks Jordan!

FWIW, it would be great if this was documented \*somewhere\*. Not certain if we have a handy place to put documentation on Clang Importer behavior for Swift developers.

> **···**
>
> > On Aug 25, 2016, at 3:11 PM, Jordan Rose via swift-dev \<swift-dev@swift.org\> wrote:
> > 
> > > On Aug 25, 2016, at 14:58, Douglas Gregor \<dgregor@apple.com \<mailto:dgregor@apple.com\>\> wrote:
> > > 
> > > > On Aug 25, 2016, at 2:48 PM, Jordan Rose \<jordan\_rose@apple.com \<mailto:jordan\_rose@apple.com\>\> wrote:
> > > > 
> > > > > On Aug 25, 2016, at 9:38, Douglas Gregor \<dgregor@apple.com \<mailto:dgregor@apple.com\>\> wrote:
> > > > > 
> > > > > > On Aug 24, 2016, at 3:57 PM, Jordan Rose \<jordan\_rose@apple.com \<mailto:jordan\_rose@apple.com\>\> wrote:
> > > > > > 
> > > > > > Hey, all. I’m here to propose predefining a macro \_\_swift\_\_ when C code is compiled with Swift. We’ve gotten a few requests for it in the past and haven’t done it so that people don’t write header files that arbitrarily restrict features when used from Swift, or check for "Swift" when they really should be checking for modules support, or Objective-C mode, or nullability support. (Or worse, they guard code under \_\_swift\_\_ and then don’t ever test it, leading to failures to import the module from Swift.)
> > > > > > 
> > > > > > However, with Swift 3, it’s now become important for Objective-C authors to be able to control how their APIs look in modern Swift 3 without disrupting existing clients on Swift 2.3. (Or just because Swift 3 style looks out-of-place in Swift 2.3.) The most obvious way to do this would be to define a macro that has the Swift version in it. For Swift version X.Y.Z, we could use something like
> > > > > > 
> > > > > > -D\_\_swift\_\_=XYYZZ
> > > > > > 
> > > > > > e.g.
> > > > > > 
> > > > > > -D\_\_swift\_\_=30001
> > > > > > 
> > > > > > for Swift 3.0.1.
> > > > > > 
> > > > > > This is option (1).
> > > > > 
> > > > > Option (1) sounds good to me. We don’t need to make this complicated.
> > > > 
> > > > Okay. Next question: two digits or three digits for the minor and patch versions?
> > > > 
> > > > - Two digits: if we ever switch to year/month combinations like C/C++, those will be higher values (unless we get to Swift 20 first).  
> > > > - Three digits: better for "fake" versions like 3.0.100.
> > > 
> > > I think we can just stick with 2 digits.
> > 
> > Okay. PR here: [[ClangImporter] Predefine \_\_swift\_\_ in imported (Obj)C code. by jrose-apple · Pull Request #4510 · apple/swift · GitHub](https://github.com/apple/swift/pull/4510/%5C).
> > 
> > Jordan