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>.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
