<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 25, 2016, at 9:38, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Aug 24, 2016, at 3:57 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div dir="auto" class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">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.)</div><div class=""><br class=""></div><div class="">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</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">-D__swift__=XYYZZ</div></blockquote><div class=""><br class=""></div><div class="">e.g.</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">-D__swift__=30001</div></blockquote><div class=""><br class=""></div>for Swift 3.0.1.<div class=""><br class=""></div><div class="">This is option (1). </div></div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Option (1) sounds good to me. We don’t need to make this complicated.</div></div></blockquote><br class=""></div><div>Okay. Next question: two digits or three digits for the minor and patch versions?</div><div><br class=""></div><div>- 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).</div><div>- Three digits: better for "fake" versions like 3.0.100.</div><br class=""><div class="">Jordan</div><div class=""><br class=""></div></body></html>