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

[Chris Lattner]

> On Jul 12, 2017, at 3:03 PM, Jordan Rose via swift-evolution <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.

> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170712/f8564ef7/attachment.html>