Combo reply...
[Proposal: 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
···
On Jul 12, 2017, at 3:58 PM, Chris Lattner via swift-build-dev <swift-build-dev@swift.org> wrote:
On Jul 12, 2017, at 3:03 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Likewise with the above, this could be much simpler.
-Chris
_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-build-dev