> On Aug 25, 2016, at 14:58, Douglas Gregor <dgre...@apple.com> wrote: > >> >> On Aug 25, 2016, at 2:48 PM, Jordan Rose <jordan_r...@apple.com >> <mailto:jordan_r...@apple.com>> wrote: >> >>> >>> On Aug 25, 2016, at 9:38, Douglas Gregor <dgre...@apple.com >>> <mailto:dgre...@apple.com>> wrote: >>> >>>> >>>> On Aug 24, 2016, at 3:57 PM, Jordan Rose <jordan_r...@apple.com >>>> <mailto:jordan_r...@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: https://github.com/apple/swift/pull/4510/ <https://github.com/apple/swift/pull/4510/>. Jordan
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
