> On Jul 12, 2017, at 3:03 PM, Jordan Rose via swift-evolution
> <[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.
>
> 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.
Likewise with the above, this could be much simpler.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
