[swift-build-dev] [swift-evolution] [swift-evolution-announce] [Review] SE-0181: Package Manager C/C++ Language Standard Support

[Daniel Dunbar]

Combo reply...

> On Jul 12, 2017, at 3:58 PM, Chris Lattner via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
>> 
>> On Jul 12, 2017, at 3:03 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md <https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md>]
>> 
>> I don't feel like I have the perspective for broad comments on the use cases for the proposal, but here are some low-level thoughts:
>> 
>> public enum CLanguageStandard {
>>     case c89
>>     case c90
>>     case iso9899_1990
>>     case iso9899_199409
>>     case gnu89
>>     case gnu90
>>     case c99
>>     case iso9899_1999
>>     case gnu99
>>     case c11
>>     case iso9899_2011
>>     case gnu11
>> }
>> 
>> I don't think it's worth having every name and every alias here. c89/gnu89, c99/gnu99, and c11/gnu11 covers all of the variants and is what's used most in practice anyway. (IIRC C89 and C90 have some tiny difference from the second standardization, but Clang ignores this difference anyway.)
> 
> I agree.  It would be worth considering splitting this into two different dimensions: base language standard (90, 94, 99, 11) vs gnu/clang extensions (on/off).  GNU extensions are generally compatible with non-extensions, so you may be able to get away with them always being enabled.

I initially thought the same thing (we should avoid the aliases and simplify as much as possible).

However, I also have a guiding philosophy that "eventually" it should be possible to target everything the tools can do with SwiftPM (consider the use case of a compiler engineer wanting to test the behavior of iso9899:1999 mode, for whatever obnoxious reason). After thinking about it more I felt that supporting all of the non-deprecated GCC/Clang modes had little downsides, and was easier to justify in terms of this philosophy. The other alternative would be to support a limited set of modes and then an "other(String)" case, but I prefer this solution to that.

Given that we anticipate replacing this case with a more comprehensive "build setting" feature at some point, I would rather KISS which in this case means making the enum definitions 1:1 with the GCC/Clang ones.

Completely disregarding the GNU/Clang extension modes (and forcing it on where supported) and then dropping down to the minimal "useful" set (C{89,9911}, C++{98,03,11,14,1z}) would also be fine with me, but it is marginally more complicated to implement/explain and I'm not sure worth it.

>> public enum CXXLanguageStandard {
>>     case cxx98
>>     case cxx03
>>     case gnucxx98
>>     case gnucxx03
>>     case cxx11
>>     case gnucxx11
>>     case cxx14
>>     case gnucxx14
>>     case cxx1z
>>     case gnucxx1z
>> }
>> 
>> Similar thoughts here. I also wonder if "gnucxx98" is redundant, given that it's already in a containing enum called "CXXLanguageStandard" (or "CPPLanguageStandard", or even "CPlusPlusLanguageStandard", depending on how that discussion goes). "gnu98" seems sufficient.

It is redundant, but it also has a very clear mapping to the GCC/Clang values. What would you call the enum values to take advantage of this duplication?

 - Daniel

> 
> Likewise with the above, this could be much simpler.
> 
> -Chris
> 
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170712/bd466012/attachment.html>