A couple more points I skipped earlier... > On Jul 12, 2017, at 3:03 PM, Jordan Rose <[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.) > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
