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

[Daniel Dunbar]

A couple more points I skipped earlier...

> On Jul 12, 2017, at 3:03 PM, Jordan Rose <jordan_rose at apple.com> 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.)
> 
> 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.
> 
> I really don't like saying "cxx1z". Can we just say "cxx17" because it's really likely we'll get it this year?

I don't want us to be in the position of making these kinds of decision. I want the one source of truth to rest with the compiler, and we will just reflect what the tools support. So, if you believe this is the right answer I think Clang should accept c++17, and then we will follow along (and deprecate the old API).

> If this were a longer-term issue (say, if there were references to "cxx2a") I'd ask what the plan is for aliases in the future. You'd want "cxx2a" and "cxx21" to eventually compare equal, right? But since this will get subsumed by build settings I think it's okay not to worry about that, or any custom standards a vendor or Clang experimenter might try to add.

I don't know that I would expect cxx2a and cxx21 to compare equal -- they would be distinct from the perspective of changing what is passed to the compiler. I would imagine if we wanted to support a more semantic notion like this, we would expose a custom API for it.

 - Daniel

> 
> Jordan

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