Combo reply...
> On Jul 12, 2017, at 3:58 PM, Chris Lattner via swift-build-dev
> <[email protected]> wrote:
>
>>
>> On Jul 12, 2017, at 3:03 PM, Jordan Rose via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-build-dev
> <https://lists.swift.org/mailman/listinfo/swift-build-dev>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
