> On Aug 25, 2016, at 2:48 PM, Jordan Rose <[email protected]> wrote:
>
>>
>> On Aug 25, 2016, at 9:38, Douglas Gregor <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On Aug 24, 2016, at 3:57 PM, Jordan Rose <[email protected]
>>> <mailto:[email protected]>> 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.
- Doug
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
