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

[Jordan Rose]

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

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.

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